There it is.

The most painful part of 2.6.13 is likely to be the fact that we made x86 use the generic PCI bus setup code for assigning unassigned resources. That uncovered rather a lot of nasty small details, but should also mean that a lot of laptops in particular should be able to discover PCI devices behind bridges that the BIOS hasn't set up.

We've hopefully fixed up all the problems that the longish -rc series showed, and it shouldn't be that painful, but if you have device problems, please make a report that at a minimum contains the unified diff of the output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us some clues.

The changes since -rc7 are pretty small, full shortlog and diffstat of that appended.

As to the new world order: I'm actually going to be away for most of next week, but in general we should now try to do all major merges within the first two weeks of the release. After that, we go into calm-down mode, and if you have work that didn't make the cut, you get to wait until 2.6.14.

The plan is that this should bring in the time between releases, so that even stuff that misses the deadline won't have to wait _too_ long for the next one.

Done.

(Well, it's going to take a while to mirror out).

That's 2.3MB of logs (even the shortlog weighs in at 5000+ lines and 201kB, if anybody cares. I didn't upload that, and the kernel mailing list limits don't allow me to put it here, but git users can do

git-rev-list --pretty=short v2.6.12..v2.6.13 | git-shortlog

to generate it. You might additionally want to add a "--no-merges" if you don't want to see people doing non-linear merges).

Using git in the linus tree:

$ git-whatchanged v2.6.12..v2.6.13 --pretty=full

You can get this:

ftp://ngc891.blogdns.net/pub/linux/misc/ChangeLog-2.6.12-2.6.13.txt

Be warn, it's about 3.7MB

It's really much nicer to just do

git log --no-merges v2.6.12..v2.6.13

which gives you a much more readable result.

git-whatchanged is useful if you also want to see the files that got changed (especially with the "-p" flag to see the whole diff), or if you want to limit it to a specific subsystem ("git-whatchanged drivers/usb"), but if you just want the log, use "git log".

That "--pretty=full" this gives you committer information (and you can do it for "git log" too), but most people probably don't care. In fact, you'd more often find yourself using "--pretty=short", which only shows the first line ("head-line" - the subject line of an email patch) of the commit message.

Additionally, you can pipe the output of "git log" to "git-shortlog", and you'll get the shortlog format (ie head-line only, and sorted by author).

Sadly, some commits ended up missing out on the author field (hey, people were getting started with git), so you have two commits like this:

        commit af25e94d4dcfb9608846242fabdd4e6014e5c9f0
        Author:  <>
        Commit: Tony Luck <tony.luck@intel.com>

            [IA64] Make ia64 die() preempt safe

            Signed-off-by: Keith Owens <kaos@sgi.com>
            Signed-off-by: Tony Luck <tony.luck@intel.com>

        commit af2c80e926ad5335d00a8d507928aff4e8ff1877
        Author: ? <?>
        Commit: Thomas Gleixner <tglx@mtd.linutronix.de>

            [MTD] ms02-nv: Fix 64bit operation

            Replace KSEG1ADDR() with CKSEG1ADDR() as the former does not work for
            64-bit configurations anymore.

            Signed-off-by: Maciej W. Rozycki <macro@infradead.org>
            Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

where the author does show up thanks to the sign-off lines, but the git author information was left empty, so the git-shortlog thing has two unattributed changes ;^p

I've written an article that surveys the current State of Linux graphics and proposes a possible path forward. This is a long article containing a lot of detailed technical information as a guide to future developers. Skip over the detailed parts if they aren't relevant to your area of work.

http://www.freedesktop.org/~jonsmirl/graphics.html

Topics include the current X server, framebuffer, Xgl, graphics drivers, multiuser support, using the GPU, and a new server design. Hopefully it will help you fill in the pieces and build an overall picture of the graphics landscape.

The article has been reviewed but if it still contains technical errors please let me know. Opinions on the content are also appreciated.

The following is a driver I would like to see included in the base kernel.

It allows OS controll of a device that synchronizes signaling hardware across a ATCA chassis.

The telecom clock hardware doesn't interact much with the operating system, and is controlled via registers in the FPGA on the hardware. It is hardware that is unique to this computer.

As per the feature-removal.txt file, I will be removing the following functions shortly:

• register_serial
• unregister_serial
• uart_register_port
• uart_unregister_port

However, there are still some drivers which use these functions:

drivers/char/mwave/mwavedd.c:   return register_serial(&serial);
drivers/char/mwave/mwavedd.c:   unregister_serial(pDrvData->sLine);
drivers/misc/ibmasm/uart.c:     sp->serial_line = register_serial(&serial);
drivers/misc/ibmasm/uart.c:     unregister_serial(sp->serial_line);
drivers/net/ioc3-eth.c:         register_serial(&req);
drivers/net/ioc3-eth.c:         register_serial(&req);
drivers/serial/serial_txx9.c:   line = uart_register_port(&serial_txx9_reg, &port);
drivers/serial/serial_txx9.c:   uart_unregister_port(&serial_txx9_reg, line);

These drivers really really really need fixing in the next few days if they aren't going to break. I hereby ask that the maintainers of the above drivers show some willingness to update their drivers.

Unfortunately, it appears that some of these drivers do not contain email addresses for their maintainers, neither are they listed in the MAINTAINERS file. (mwavedd and serial_txx9).

Please note that this is the last warning folk will have before the functions are removed.

In addition, the following drivers declare functions of the same name. The maintainers of these need to look to see why, and eliminate them where possible.

drivers/serial/crisv10.c:register_serial(struct serial_struct *req)
drivers/serial/crisv10.c:void unregister_serial(int line)

I'll have a quick look at mwave. If I remember rightly it just needs to tell someone that an "ISA" 16450 serial port materialised by magic at the addresses it selected.

The mwave firmware is loaded into a DSP and until its loaded there isn't a serial port

I think that it shouldn't be too big a problem - maybe just using serial8250_register_port() and serial8250_unregister_port() instead of register_serial()/unregister_serial(), and changing the structure.

The key thing is that port.dev should be set appropriately and the relevant calls to serial8250_suspend_port/serial8250_resume_port be made (or port.dev should be NULL if no power management is expected - in which case it may be managed as a generic platform port.)

Also, port.uartclk must be set, and since this is an add-in card, it should not be using BASE_BAUD but the clock rate for the UART on the card itself. (BASE_BAUD being an architecture defined constant has no business being used in connection with add-in cards with on-board UART clock generators.)

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/

• Included Alan's big tty layer buffering rewrite. This breaks the build on lots of more obscure character device drivers. Patches welcome (please cc Alan).

Here is a working swap prefetching patch for 2.6.13. I have resuscitated and rewritten some early prefetch code Thomas Schlichter did in late 2.5 to create a configurable kernel thread that reads in swap from ram in reverse order it was written out. It does this once kswapd has been idle for a minute (implying no current vm stress). This patch attached below is a rollup of two patches the current versions of which are here:

http://ck.kolivas.org/patches/swap-prefetch/

These add an exclusive_timer function, and the patch that does the swap prefetching. I'm posting this rollup to lkml to see what the interest is in this feature, and for people to test it if they desire. I'm planning on including it in the next -ck but wanted to gauge general user opinion for mainline. Note that swapped in pages are kept on backing store (swap), meaning no further I/O is required if the page needs to swap back out.

I know you have some doubts about usefulness, etc. Here are a couple of facts, that I hope show that Linux should benefit from having FUSE:

• total number of downloads from SF: ~25000
• number of downloads of last release (during 3 months): ~7000
• number of distros carrying official packages: 2 (debian, gentoo)
• number of publicly available filesystems known: 27
• of which at least 2 are carried by debian (and maybe others)
• number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL)
• biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s
• mailing list traffic 100-200 messages/month
• have been in -mm since 2005 january

I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, there seems to be no interest in working on that.

The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing.

Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader.

It's based on some source code originally made available by the vendor (as BSD/GPL dual licensed code), but has undergone significant changes to make it more compliant with the general kernel community coding practise.

As this is the first PCMCIA driver that I'm involved in, please let me know if I missed something.

If there are no objections, I'd like to see it included in mainline. Thanks!

Attached is a backport of the latest forcedeth version to 2.4. It includes lots of changes, among them:

• a critical bugfix for nv_open(): ifdown/ifup cycles resulted in an incomplete initialization that causes hangs after a few MB network traffic.
• jumbo frame support
• far better ethtool support
• 64-bit dma support
• support for additional nforce versions.

It compiles and boots, but I can't test it properly. Could you give it a try?

Following-up to the Cardman 4040 driver, I'm now sumitting a driver for the Cardman 4000 reader. It is, too, a PCMCIA smartcard reader and the predecessor of the 4040.

From a technical point of view, the two devices have nothing in common, so there is no possibility of code sharing.

Please consider mergin mainline, thanks.

Note: The patch is incremental to the Cardman 4040 driver that has already been submitted.

From my past experience (I'm involved in writing smartcard reader drivers for some time now), users of smartcard readers tend to be "typical corporate users" who won't run anything but the distribution kernel.

I really doubt that the drivers would get much more testing in -mm than they would in mainline.

Also, what is the point of putting entirely new code (no changes to existing code!) into -mm? I understand that changes to existing code can inarguably benefit from some testing in -mm first.

But new drivers? Where's the point? The devices are not supported in the existing kernel, so it cannot get worse by having a driver (even if it still contains one or the other bug).

I notice DaveM's taken over serial maintainership. Please arrange for serial patches to be sent to davem in future, thanks. (All ARM serial drivers are broken as of Tuesday.)

I might take a different view if I at least had a curtious CC: of the patch, which I had already asked akpm to reject.

Thanks. That's another subsystem I don't have to care about anymore.

Guys, stop being stupid about things. I already sent rmk an email in private. And Alan, there's absolutely no point in making things even worse.

Mistakes happen, and the way you fix them is not to pull a tantrum, but tell people that they are idiots and they broke something, and get them to fix it instead.

You don't have to be polite about it, and swearing is fine. So instead of saying "I don't want to play any more because Davem made a mistake", say something like "Davem is a f*cking clueless moron, here's what he did and here's why it's wrong".

Notice? In both cases you get to vent your unhappiness. In the second case, you make the person who made a mistake look bad. But in the first case, it's just yourself that looks bad.

As per the new merge policies that were discussed during LKS in Ottawa earlier during the summer, I'm going to accept new stuff for 2.6.14 only during the first two weeks after 2.6.13 was released.

That release was ten days ago, so you've got four more days before I don't want any big merges.

After that, I'll do a -rc1, and then we're supposed to just do fixes and thus only work on any regressions and other immediate issues.

I've been merging a lot lately (happily, I got some work done during the trip last week), so we certainly already have enough for 2.6.14. But I just wanted to remind people that if they expected me to merge your work, you're getting closer to the cut-off point..

(Of course, if you already sent me a pointer, and I haven't merged it yet, it might be because I missed something during travels, so please do re-send in that case)