Ingo Molnar summarized his pull request for changes to the x86 architecture bound for mainline inclusion in 2.6.25 noting, "it's not a small merge, it consists of 908 commits from 96 individual arch/x86 developers (!)". He continued, "a number of core files are changed as well: most notably percpu, debugging details, timers, the firewire remote debugging patch and ... the KGDB remote debugging stub in kernel/kgdb.c." He went on to detail the extent of the testing this tree has received, "in the past few weeks tens of thousands of random x86.git bzImages were successfully built and booted on a number of (commodity) 32-bit and
64-bit testsystems - and there has been a fair amount of test exposure on -mm as well." Regarding the remote kernel debugger, Ingo explained:
"We tested KGDB to be merge-worthy within the x86 architecture (the only supported architecture for now) and it's better to have kernel/kgdb.c than arch/x86/kernel/kgdb.c. The code is reasonably clean and the user-space exposure is small - the only real exposure is the decades-old remote GDB protocol. We are happy to fix up any further cleanliness comments that people might have - but we really wanted to start somewhere and get this thing moving. As an added bonus: finally a kernel debugger that can be read without puking too much ;-) [anyone remember KDB?]"
Stefan Richter posted the IEEE1394 subsytem and FireWire subsystem TODO lists noting, "it seems also appropriate to disclose the current manpower behind FireWire driver development and maintenance. There are just two people who regularly work on the drivers: Kristian Høgsberg (author and maintainer of the new firewire subsystem, in the past also involved with the old ieee1394 subsystem) and me (co-maintainer of both the new and old subsystems). But we both have a lot of other projects going on at the moment."
The current IEEE1394 subsystem is available for the 2.6 and 2.4 kernels, also known as the Linux1394 driver stack. Kristian Høgsberg started development of the new FireWire stack, nicknamed "Juju", in December of 2006. The Linux1394 website notes, "when the new stack's initial bugs and missing features have been addressed, it is anticipated that the old driver stack (ieee1394, ohci1394, pcilynx, raw1394, video1394, dv1394, sbp2, eth1394) will be scheduled for removal from the mainline kernel sources. (There is by the way no replacement for pcilynx planned at the moment, because this controller has become very rare.) The main reasons to replace the old stack by the new one are: lower code footprint, hence lower maintenance cost; better security; consolidation of the currently three or four different userspace ABIs (depending on how you count them) into a single, modern ABI."
Linux creator Linus Torvalds released the 2.6.22-rc7 kernel saying, "it's hopefully (almost certainly) the last -rc before the final 2.6.22 release, and we should be in pretty good shape. The flow of patches has really slowed down and the regression list has shrunk a lot." He briefly summarized the changes in this latest release candidate, "the patches are mostly trivial fixes, a few new device ID's, and the appended shortlog really does pretty much explain it," adding, "final testing always appreciated, of course".
The previous stable kernel, 2.6.21, was released a little over two months ago on April 25'th [story]. An overview of all the changes merged into the latest version of the kernel is maintained in the Kernel Newbies wiki. Included in the list of changes are the SLUB allocator which replaced the slab allocator, a new wireless stack, a new firewire stack [story], and support for the Blackfin architecture. Source level changes can be tracked via the gitweb interface to Linus' kernel tree.
"Ok, the merge window has closed, and 2.6.22-rc1 is out there," Linus Torvalds announced on the Linux Kernel Mailing List. He noted that there were a large number of changes, "almost seven thousand files changed, and that's not double-counting the files that got moved around." As to what was changed, Linus summarized, "architecture updates, drivers, filesystems, networking, security, build scripts, reorganizations, cleanups.. You name it, it's there." He went on to add:
"You want a new firewire stack? We've got it. New wireless networking infrastructure? Check. New infiniband drivers? Digital video drivers? A totally new CPU architecture (blackfin)? Check, check, check.
"That said, I think (and certainly hope) that this will not be nearly as painful as the big fundamental timer changes for 2.6.21, and while there are some pretty core changes there (like the new SLUB allocator, which hopefully will end up replacing both SLAB and SLOB), it feels pretty solid, and not as scary as ripping the carpet from under the timer infrastructure."
Kristian Høgsberg posted an update on the effort to rewrite the Linux kernel FireWire stack [story] explaining, "as you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story." He went on to request the stack's inclusion in the mainline kernel, listing the following highlights: the new FireWire stack "has been in Fedora rawhide (development branch) and -mm for 3 months, will be shipping in Fedora 7; backwards compatible at the library level, existing user space libraries have been ported to use the new user space interface; less than 8k lines of code compared to 30k lines of code in the old stack, and a similar size reduction in the sizes of the .ko's; no kernel threads, compared to one subsystem thread and one thread per FireWire controller in the old stack; one user space interface to support zero-copy scatter-gather streaming, as opposed to the old stacks 4 (was 5) different streaming interfaces; per-device device files, letting userspace set up more finegrained access control, such as preventing direct access to FireWire storage devices."
Kristian went on to note the following regressions when comparing the new stack to the old: "eth1394 not ported over, there is nothing preventing this from being done, though, but there's a couple of infrastructure bits that aren't done yet; no support for the PCILynx chipset, nobody has this chipset anymore, and the pcilynx driver in the old stack is bit-rotting anyway; some SBP-2 (storage) devices fail after significant amounts of IO, not clear what the problem is, but I can reproduce it here and am working on fixing it." Regarding his plans going forward, "what I'd like to propose is that we carry both the new and the old stack in mainline for a few releases. Once we've reached a satisfactory level of stability and worked through what regressions there may be, we can consider deprecating the old stack."