"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."

"'Const' has *never* been about the thing not being modified. Forget all that claptrap. C does not have such a notion," began Linus Torvalds, responding to a query about why kfree() takes a const pointer. He continued, "'const' is a pointer type issue, and is meant to make certain mis-uses more visible at compile time. It has *no* other meaning, and anybody who thinks it has is just setting himself up for problems." He offered two explanations, beginning with simple C semantics, "from a very obvious and very *real* caller perspective, 'free()' really doesn't change the thing the pointer points to. It does something totally different: it makes the *pointer* itself invalid." He then added his second reason, "anything that *can* take a const pointer should always do so. Why? Because we want the types to be as tight as possible, and normal code should need as few casts as possible." When it was pointed out that GCC 4.2 displays warnings when casting a const pointer to a non-const, Linus replied:

"Either don't use a broken compiler (casting a const pointer to a non-const is definitely not a bug), or cast to 'unsigned long' (if it still complains, now the compiler is not just stupid, it's broken). The whole point of memory management is that we know how pointers work, and understand that they have a *bit* representation, not just the C semantics."

"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."

"This week, a total of 49 oopses and warnings have been reported, compared to 53 reports in the previous week," Arjan van de Ven noted, sending out a list of the week's top 10 kernel oopses. Al Viro suggested, "FWIW, people moaning about the lack of entry-level kernel work would do well by decoding those to the level of 'this place in this function, called from <here>, with so-and-so variable being <this>' and posting the results." This was met by multiple requests for documentation on how to actually decode an oops. Linus Torvalds explained:

"It's actually not necessarily at all that trivial, unless you have a deep understanding of the code generated for the architecture in question (and even then, some oopses take more time to figure out than others, thanks to inlining and tailcalls etc). If the oops happened with a kernel you generated yourself, it's usually rather easy. Especially if you said 'y' to the 'generate debugging info' question at configuration time."

Linus went on to detail how to debug a random oops reported on the lkml, "you will generally have to disassemble the hex sequence given in the oops (the 'Code:' line), and try to match it up against the source code to try to figure out what is going on." He then offered a number of tips on how this is best accomplished, continuing with an example walking through one of the reports oops. Al Viro replied describing his own methods of accomplishing the same thing, walking through of another oops and isolating a bug.

"It's been two weeks since rc6, but let's face it, with xmas and new years (and birthdays) in between, there hasn't actually been a lot of working days, and the incremental patch from -rc6 is about half the size of the one from rc5->rc6," began Linus Torvalds, announcing the release of the 2.6.24-rc7 Linux kernel. He then quipped, "and I'll be charitable and claim it's because it's all stabilizing, and not because we've all been in a drunken stupor over the holidays." Linus quickly summarized the changes:

"The shortlog (appended below) is short and fairly informative. It's all really just a lot of rather small changes. The diffstat shows a lot of one- and two-liners, with just a few drivers (and the Cell platform) getting a bit more attention, and the SLUB support of /proc/slabinfo showing up as a blip."

"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)."