"As you probably know there is a trend in enterprise computing towards networked storage. This is illustrated by the emergence during the past few years of standards like SRP (SCSI RDMA Protocol), iSCSI (Internet SCSI) and iSER (iSCSI Extensions for RDMA)," began Bart Van Assche, proposing that SCST be merged into the mainline kernel. He suggested that while similar to the STGT project which has been part of the mainline kernel since 2.6.20, "SCST is superior to STGT with respect to features, performance, maturity, stability, and number of existing target drivers. Unfortunately the SCST kernel code lives outside the kernel tree, which makes SCST harder to use than STGT."
SCSI subsystem maintainer, James Bottomley, was not convinced, explaining:
"The two target architectures perform essentially identical functions, so there's only really room for one in the kernel. Right at the moment, it's STGT. Problems in STGT come from the user<->kernel boundary which can be mitigated in a variety of ways. The fact that the figures are pretty much comparable on non IB networks shows this. I really need a whole lot more evidence than at worst a 20% performance difference on IB to pull one implementation out and replace it with another. Particularly as there's no real evidence that STGT can't be tweaked to recover the 20% even on IB."
"For the last release, I stated that I thought the 220.127.116.11 release would be the last one in the 2.6.22.y series. Since then, I've received a number of other patches that would be nice to have in the .22.y tree," explained Greg KH. He continued:
"So, for a while, I'll keep the 2.6.22.y tree open, doing new releases every once in a while as they accumulate. I do this, for no other than the selfish reason that I use it every day on my openSuSE 10.3 boxes as that is the kernel base that release is on :)"
Greg KH and Chris Wright have been maintaining a -stable 2.6.x.y patchset for the 2.6.x and 2.6.(x-1) kernels since March of 2005. 2.4 stable kernel maintainer Willy Tarreau has also maintained patches against the 2.6.20 branch since August of 2007, though noted that he'll switch to maintaining the stable 2.6.22 branch once Greg finishes. Adrian Bunk also continues to maintain a -stable 2.6.16 branch of the Linux kernel.
Greg KH and Chris Wright have been maintaining a -stable 2.6.x.y patchset for the 2.6.x and 2.6.(x-1) kernels since March of 2005. Thus, with the current stable release being 2.6.22, they maintain -stable patches for 2.6.22 and 2.6.21. 2.4 stable kernel maintainer Willy Tarreau noted the currently high patch rate in each of the 2.6 -stable trees and decided to maintain -stable patches against the 2.6.20 tree until things calm down. Adrian Bunk also continues to maintain a -stable 2.6.16 branch of the Linux kernel. Willy explained about his new 2.6.20 -stable patches:
"I proposed Chris and Greg to continue issuing a few more 2.6.20 releases during the time needed for 2.6.21 and 2.6.22 to show a significant drop in their patch rates, which hopefully will be just a matter of a few releases.
"My goal is *not* to do all the hard work they do, but just to backport from their patches those which are meaningful for 2.6.20. For this reason, 2.6.20 releases will always be slightly late and should not contain patches not merged in more recent releases."
Avi Kivity [interview] announced significant performance improvements and support for running 32-bit Windows Vista as a guest within the latest release of KVM. Originally merged into the 2.6.20 mainline Linux kernel [story], KVM stands for Kernel-based Virtual Machine, "a full virtualization solution for Linux on x86 hardware containing virtualization extensions". Regarding the new release, Avi announced:
"The happy theme of today's kvm is the significant performance improvements, brought to you by a growing team of developers. I've clocked kbuild at within 25% of native. This release also introduces support for 32-bit Windows Vista."
Linux creator Linus Torvalds announced the release of the 2.6.21 kernel, "if the goal for 2.6.20 was to be a stable release (and it was), the goal for 2.6.21 is to have just survived the big timer-related changes and some of the other surprises (just as an example: we were apparently unlucky enough to hit what looks like a previously unknown hardware errata in one of the ethernet drivers that got updated etc)." Regarding the the dynticks code which was merged in -rc1 [story] he said, "the big change during 2.6.21 is all the timer changes to support a tickless system (and even with ticks, more varied time sources). Thanks (when it no longer broke for lots of people ;) go to Thomas Gleixner and Ingo Molnar and a cadre of testers and coders." He went on to note, "of course, the timer stuff was just the most painful and core part (and thus the one that I remember most): there's a lot of changes all over. The appended changelog is just for the fixes since -rc7, so that doesn't look very impressive, the full changes since 2.6.20 are obviously a *lot* bigger (and you're better off reading the individual -rc changelogs)." Linus finished with a running joke about the many debates centered around current CPU scheduler efforts [story], quipping, "we now return you to your regular scheduler discussions".
Avi Kivity is the lead developer and maintainer of the Kernel-based Virtual Machine project, better known as kvm. The project was started in mid-2006, and has been part of the Linux kernel since the 2.6.20 release in February of 2007. kvm is a full virtualization system for x86-based Linux hosts, allowing users to run isolated x86 guest operating systems in virtual machines.
Adrian Bunk posted a couple lists of known regressions that found their way into the 2.6.21-rc1 kernel [story] since the release of the 2.6.20 kernel [story]. Adrian notes that his lists only include bugs that are not yet fixed in Linus' -git tree. In an updated version of his lists he included 19 known regressions, including links to bugzilla or the appropriate mailing list discussion thread. The lists track who submitted the bug, who is currently handling it, who caused it if known, a link to a patch that fixes the problem if any, and the current status.
Following the release of the 2.6.20 kernel [story] Andrew Morton [interview] posted a list of patches in his -mm kernel, summarizing for each his plans as to whether or not they will be pushed upstream for inclusion in the upcoming 2.6.21 kernel. Andrew commented, "I'm getting fed up of holding onto hundreds of patches against subsystem trees, sending them over and over again and seeing nothing happen. I sent 242 patches out to subsystem maintainers on Monday and look at what's still here." In response to some confusion as to what happens to these patches, he went on explain, "once a subsystem has a subsystem tree (git or quilt) I basically never merge anything which belongs to that tree. It's always originator->mm->subsystemtree->Linus".
Linux creator Linus Torvalds announced the release of the 2.6.20 kernel, summarizing, "a lot of stuff. All over. And KVM." He further noted, "I tried rather hard to make 2.6.20 largely a 'stabilization release'. Unlike a lot of kernels lately, there aren't really any big fundamental changes to some core infrastructure area, and while we always have bugs, I really am hoping that we fixed many more than we introduced." His announcement started with a news parody, "in a widely anticipated move, Linux 'headcase' Torvalds today announced the immediate availability of the most advanced Linux kernel to date, version 2.6.20." Linus continued:
"As ICD head analyst Walter Dickweed put it: "Releasing a new kernel on Superbowl Sunday means that the important 'pasty white nerd' constituency finally has something to do while the rest of the country sits comatose in front of their 65" plasma screens."
"Walter was immediately attacked for his racist and insensitive remarks by Geeks without Borders representative Marilyn vos Savant, who pointed out that not all of their members are either pasty nor white. "Some of them even shower!" she added, claiming that the constant stereotyping hurts nerds' standing in society.
Geeks outside the US were just confused about the whole issue, and were heard wondering what the big hoopla was all about. Some of the more culturally aware of them were heard snickering about balls that weren't even round.
Linux creator Linus Torvalds announced the 2.6.20-rc6 release candidate kernel, "it's been more than a week since -rc5, but I blame everybody (including me) being away for Linux.conf.au and then me waiting for a few days afterwards to let everybody sync up." He asked that people test the regressions reported against earlier release candidates [story], "so that we can confirm whether they are still active and relevant." Linus noted that he hoped this would be the final release candidate before 2.6.20 is released, then went on to discuss what's new:
"As to -rc6 itself: the bulk of it are the MTD updates (including a few new drivers), and the POWER update (and the bulk of _that_ in terms of patch size being defconfig updates ;)
"But there's various random fixes in infiniband, DVB, network drivers, scsi, usb, some filesystems (cifs, jffs2, nfs, ntfs, ocfs2) as well as core networking too. Oh, and KVM, of course. And stuff I probably have already forgotten."
Adrian Bunk posted a list of known regressions in the latest 2.6.20-rc4 Linux kernel compared to the previous 2.6.19 stable release [story]. In two emails, he listed six regressions that don't have fixes yet, and six regressions with fixes that haven't been merged yet.
In another email thread, Linux creator Linus Torvalds noted that his goal for 2.6.20 is to focus primarily on stability. He also noted that he intends to release the stable kernel at some point after linux.conf.au which is happening this year in Sydney, Australia between January 15th and 20th. He explains, "hopefully 'final -rc' before LCA, but I'll do the actual 2.6.20 release afterwards. I don't want to have a merge window during LCA, as I and many others will all be out anyway. So it's much better to have LCA happen during the end of the stabilization phase when there's hopefully not a lot going on. (Of course, often at the end of the stabilization phase there is all the 'ok, what about regression XyZ?' panic)"
A new feature that will first be availble in the upcoming 2.6.20 kernel is KVM, a Kernel-based Virtual Machine. The project's webpage describes KVM as, "a full virtualization solution for Linux on x86 hardware. It consists of a loadable kernel module (kvm.ko) and a userspace component. Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc." The project's FAQ explains that the functionality requires "an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V)." The userland aspect of KVM is a slighlty modified version of qemu, used to instantiate the virtual machine.
Ingo Molnar [interview] announced a new patch introducing paravirtualization support for KVM, outdating the KVM FAQ which in comparing KVM to Xen notes, "Xen supports both full virtualization and a technique called paravirtualization, which allows better performance for modified guests. kvm does not at present support paravirtualization." In describing his patch which is against the 2.6.20-rc3 + KVM trunk kernel, Ingo said it, "includes support for the hardware cr3-cache feature of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)". He went on to add, "some aspects of the code are still a bit ad-hoc and incomplete, but the code is stable enough in my testing and i'd like to have some feedback." In a series of benchmarks, he found 2-task context switch performance to be improved by a factor of four, while "hackbench 1" showed twice as good performance, and "hackbench 5" showed a 30% improvement. His email goes on to detail how the paravirtualization works.
Andrew Morton [interview] posted his patch queue with numerous comments about merge plans into the mainline kernel. Among his comments he noted that he would not yet be merging the Reiser4 filesystem [story], "reiser4. I was planning on merging this, but the batch_write/writev problemight wreck things, and I don't think the patches arising from my recent partial review have come through yet. So it's looking more like 2.6.20."
A large discussion followed Andrew's posting that focused on the current kernel development process [story]. Andrew expressed his concerns on what's currently happening, "people seem to treat the stabilisation period as a wonderful quiet time in which to run off and develop new features, rather than participating in the stabilisation. This has the following effects: 1: release cycles get longer 2: the kernel has more bugs 3: we put new features into the kernel faster than we otherwise would (see 2:, above)." Alan Cox [interview] proposed an idea, "a suggestion from the department of evil ideas: Call even cycles development odd ones stabilizing. Nothing gets into an odd one without a review and linux-kernel signoff/ack?" Linus Torvalds replied favorably, going on to note that he was surprised at how well the decision to only accept big merges in the two weeks following a major release has been accepted, "I actually expected people to dislike arbitrary rules more than they do, but I've come to believe that people _like_ having rules that they have to obey, as long as it's not a big pain for them. In other words, arbitrary rules are not actually disliked at all, people actually _like_ them, because suddenly there's less need for making unnecessary judgement decisions." Linus went on to spell out the idea further, "2.6.<odd> is 'the big initial merges with all the obvious fixes to make it all work' (ie roughly the current -rc2 or perhaps -rc3). 2.6.<even> is 'no big merges, just careful fixes' (ie the current 'real release')". He went on to caution:
"That said, I think Andrew was of the opinion that it doesn't really _fix_ anything, and he may well be right. What's the point of the odd release, if the weekly snapshots after that are supposed to be strictly better than it anyway? So I think I may like it just because it _seems_ to combine the good features of both the old naming scheme and the current one, but I suspect Andrew may be right in that it doesn't _really_ change anything, deep down."