"Thousands of Neo FreeRunners have been loaded into planes and fired around the world," announced Sean Moss-Pultz, the Openmoko CEO, in a frequently philosophical email titled "let us impact the material world", posted to the Openmoko community mailing list. He continued, "many of our distributors have already begun shipping. In about another week, Steve and Harry will announce the opening of our own webshop." The CAD files for building the smartphone hardware are available under the Creative Commons, and the software has been released under the GPL, including a patched 2.6.24 Linux kernel. Sean continued, "whenever I talk publicly about Openmoko, or so it seems, the following question is asked: How can you compete again the giants of this industry? For most of us, I'd like to think, the answer is obvious. Instead of answering, I usually return their question: How can they compete against us?" He explained:

"Openmoko is the collective creation of amateurs working on exactly what we love. They are professionals, some doing what they love, most working towards the next paycheck. At certain times, the amateur has a distinct advantage over the professional. A professional knows what they can deliver, and rarely goes beyond it. An amateur has no concept of their limitations and usually goes well beyond them. Experience teaches us our limits. When we have learned that and become complacent, we are finished, because our work can be calculated and measured. Our work ceases to be a weapon."

"The release is out there (both git trees and as tarballs/patches), and for the next week many kernel developers will be at (or flying into/out of) LCA in Melbourne, so let's hope it's a good one," said Linus Torvalds, announcing the 2.6.24 Linux kernel. He noted, "nothing earth-shattering happened since -rc8". Source level changes can be viewed via the gitweb interface. A nice overview of all changes can be found at Kernel Newbies.

In a followup email, Linus added:

"Since I already had two kernel developers asking about the merge window and whether people (including me) traveling will impact it, the plan right now is to keep the impact pretty minimal. So yes, it will probably extend the window from the regular two weeks, but *hopefully* not by more than a few days."

"I do hate doing -rc's for so long, but I hate releasing when not feeling it's simmered enough even more. And the changes since -rc7 are bigger than the changes between -rc6 and -rc7 were (partly probably because people were still on vacation between -rc6 and -rc7, so we had something of a small trickle come in afterwards)," Linus Torvalds began, explaining why he posted another release candidate rather than the official 2.6.24 kernel. He continued, "that said, the changes here really aren't that big, and the shortlog is fairly boring. So I'm pretty sure this is the last -rc, and the final 2.6.24 will probably be out next weekend or so. But in the meantime, let's give this a final shakedown, and see if we can fix any last regressions still." Linus went on to summarize the changes:

"Drivers, networking, some arch updates, and ACPI. A fair number of really small commits. I honestly can't really improve on the appended shortlog - there isn't any over-arching theme, except for 'lots of small boring fixes'. Which is as it should be, of course."

"It's been a week, and I promised to be a good boy and try to follow my release rules, so here is the next -rc," Linus Torvalds said, announcing the 2.6.24-rc5 kernel. He noted:

"Things _have_ slowed down, although I'd obviously be lying if I said we've got all the regressions handled and under control. They are being worked on, and the list is shrinking, but at a guess, we're definitely not going to have a final 2.6.24 out before xmas unless santa puts some more elves to work on those regressions. So any elves out there - please keep working."

Linus added that there were no major changes in the latest release candidate, stating that because of this it wasn't worth posting a diffstat, "it only highlights a textually big PA-RISC revert, and the powerpc defconfig updates. And the Blackfin SPI driver. The rest is largely random noise in various subsystems (drivers/net, xfs filesystem, and arch updates are some of the areas that show more changes)."

"We should have one week between -rc releases, but I was gone for a week over thanksgiving (as were some other kernel developers), so this one is a bit late. It's been almost the rule rather than the exception, but I promise I'll be better..." began Linus Torvalds, announcing the 2.6.24-rc4 kernel. He noted, "there aren't a lot of exciting changes here, but there's still a _lot_ more churn than I really hoped for at the -rc4 stage. Blackfin, MIPS and Power do stand out in the diffstats, but ARM and x86 got some updates too." Linus continued:

"And we had some ACPI churn (processor throttling etc), along with various driver updates: ATA, IDE, infiniband, SCSI, USB and network drivers.. And on the filesystem side, cifs, NFS, ocfs2 and proc. Ugh. Too much. [...] That said, none of the changes are really _exciting_ or really scary. And we should have fixed a number of regressions, although more certainly remain."

Linux creator Linus Torvalds announced the third release candidate for the upcoming 2.6.24 kernel summarizing, "hmmm.. Lots of small fixes, some cleanups, and a few things like the cris updates that aren't really either, but which won't affect any normal user, and will hopefully make it easier to sync up in the future. Network driver fixes, some IDE and infiniband updates, some late cpufreq updates, and a hwmon update." He continued:

"On the architecture side, in addition to the afore-mentioned cris updates, there are some sh, arm, powerpc and mips updates, and also one final x86 unification cleanup (and I really mean it - the rest can wait until after 2.6.24, but with this one the x86 configuration really is fairly merged, and both i386 and x86_64 are really just special cases of the 'x86' architecture in the configurator)."

"Yeah, don't remind me - it's late," began Linus Torvalds, announcing the second 2.6.24 release candidate, "there was nothing in particular holding this thing up, I just basically just forgot to cut a -rc2 release last week." He went on to list some of the changes:

"There's not a lot of hugely exciting stuff here. Some arch updates: MIPS, arm, blackfin, x86, sparc[64], sh, s390.. Also various driver updates: libata, IDE, networking, DVB.. And some more fallout from the scatter-gather changes. Some scheduler cleanups, and also fixing the CPU usage statistics that got scrogged at some point."

Linus noted that while there were no major changes, the shortlog was still too large to post to the list. He suggested using the command git shortlog v2.6.24-rc1 to see all changes since the last release candidate, "but quite frankly, it's no Leo Tolstoy. If you have trouble falling asleep, you might try to print it out and take it to bed with you: it's not going to be more than just a couple of pages ('use 2nup and save a tree'), but I dare you to actually get to the end. Snooze city."

"This may count as one of the biggest -rc releases ever. It's humongous. Usually the compressed -rc1 diffs are in the 3-5MB range, with occasional smaller ones, and the occasional ones that top 6M, but this one is *eleven* megs," Linus Torvalds announced the first release candidate of the upcoming 2.6.24 kernel. He summarized some of the changes, "in short, we just had an unusually large amount of not just x86 merges, but also tons of new drivers (wireless networking stands out, but is by no means the only thing - we've got dvb, regular wired network, mmc etc all joining in), and a fair amount or architecture stuff, filesystems, networking etc too." He added:

"In other words, I don't even know where to start. The big noticeable thing is the x86 merge, and I think we all fervently hope that it won't cause any issues. So far it's been pretty smooth sailing. Knock wood. Less smooth has the scatter-gather changes to the block layer been, but they are hopefully all in reasonable shape by now too. And the VM changes? I honestly hope nobody even notices. Same goes for some of the VFS layer changes that affected basically every filesystem (although in mostly very straightforward ways)."

When the same patchset arrived on the Linux Kernel mailing list from multiple sources, Christoph Hellwig asked, "any reason we've got this patchset posted by three people now? :)" Andrew Morton retorted, "presumably because I haven't been merging it." He went on to explain:

"I was in bugfix-only mode from a week prior to 2.6.24 release and during the merge window. Partly caused by the already-idiotic amount of stuff we had queued for 2.6.24, partly because we needed to concentrate on stabilising the 2.6.25 patchpile rather than writing new stuff.

"And partly to send the signal that rather than beavering away on new features all the time, we should also be spending some (more) time testing, reviewing and bugfixing the current and soon-to-be-current code. Probably I should have been more explicit about it, but it wasn't really planned. Next time I'll send more 'thanks, I parked this for consideration at a more appropriate time' emails."

Jeff Garzik posted a series of nine patchs to the lkml titled to "remove [the] 'irq' argument from all irq handlers", explaining, "the overwhelming majority of drivers do not ever bother with the 'irq' argument that is passed to each driver's irq handler. Of the minority of drivers that do use the arg, the majority of those have the irq number stored in their private-info structure somewhere." He noted that he had no intention to push the patches upstream anytime soon.

Feedback was entirely positive, with Thomas Gleixner suggesting, "Full ACK. We should do this right at the edge of -rc1. And let's do this right now in .24 and not drag it out for no good reason." Ingo Molnar concurred, "full ACK on the concept from me too. Please go ahead! :)" Eric Biederman noted that there was still work to be done, "the practical question is how do we make this change without breaking the drivers that use their irq argument." Jeff agreed, explaining why the code won't be pushed upstream during -rc1, "I am finding a ton of bugs in each get_irqfunc_irq() driver, so I would rather patiently sift through them, and push fixes and cleanups upstream. Once that effort is done, everything should be in the 'trivial' pile and not have the logic that you are worried about (and thus there would be no need to add an additional branch to the irq handling path)."

"This is a request to merge KGDB into the mainline kernel," Jason Wessel announced, posting a series of patches aiming toward that goal. He continued, "as of right now KGDB is comprised of 21 different patches adding in the core api and docs first and then working up to add drivers and arch specific support to KGDB. The patches were broken down into logical pieces for review and comments." He went on to explain:

"The intent of the KGDB patches is to unify the KGDB support across all the architectures that elect to implement the KGDB functionality by providing a common core and an arch specific stub. For quite some time there has been different features and uses of KGDB across the most popular architectures. Having a common core that takes care of protocol parsing and the typical use case of software breakpoints should eliminate the inconsistencies across the archs as well as making it easier to add KGDB support to a new arch."

Andrew Morton, who has been supportive of getting a kernel debugger into the mainline kernel, explained that it was too late in the 2.6.24 review cycle to merge KGDB, meaning it would have to wait for 2.6.25 at the earliest, "this won't work very well. There's a lot of review work to be done here, and a lot of it by busy architecture maintainers. Expecting people to do all this review and test work late in the merge window when they're all madly scrambling to get their bugs^Wpatches into mainline is not reasonable. This should all have started a month ago. So we're looking at a 2.6.25 merge for this work."

"It contains lots of scheduler updates from lots of people - hopefully the last big one for quite some time," began Ingo Molnar, describing his merge request for the linux-2.6-sched git tree. He continued, "most of the focus was on performance (both micro-performance and scalability/balancing), but there's the fair-scheduling feature now Kconfig selectable too. Find the shortlog below." Ingo noted, "code that is touched outside of the scheduler: the KVM bits were acked by Avi, the net/unix change is trivial and only affects sync wakeups, ditto the fs/pipe.c changes - but i can push those separately if it needs an ack from David first." He then concluded:

"Testing status: the changes are chronological and all the interactivity-impacting changes are near the head of the queue and most of them were done weeks ago, and were thus part of the CFS-v22 backport series - which was tested by many people. There are no known regressions at the moment. It's all fully bisectable."

Avi Kivitiy posted numerous KVM updates which Linus Torvalds merged into his mainline kernel source tree to be included in the upcoming 2.6.24 kernel. Avi summarized:

"Highlights include in-kernel pic/lapic/ioapic emulation, improved guest support, preemptibility, an improved x86 emulator, and a fair amount of cleanup.

"The changes outside drivers/kvm/ and include/linux/kvm*.h fix the CR8 mask definition (which is not otherwise used in the kernel) and expose some ioapic register definitions even if ioapic support is not compiled in. The diff is appended below."

Andrew Morton posted his first -mm patchset against the recently released 2.6.23 kernel, preparing for a big merge of patches bound for inclusion in the upcoming 2.6.24 kernel. He noted:

"I've been largely avoiding applying anything since rc8-mm2 in an attempt to stabilise things for the 2.6.23 merge.

"But that didn't stop all the subsystem maintainers from going nuts, with the usual accuracy. We're up to a 37MB diff now, but it seems to be working a bit better."