login
Search
"Ahoy me laddies (and beauties)," Linux creator Linus Torvalds began, announcing the seventh release candidate for the upcoming 2.6.23 kernel, "time for the traditional 'Talk Like a Pirate Day' kernel release!" He noted, "now, last year we had a full release (2.6.18 was immortalized on TLAP-2006), but this year I'm chickening out, and we're just doing what is hopefully going to be the last -rc release for the 2.6.23 series." Full source changes can be viewed via the gitweb interface. Linus also offered a brief summary of the changes:
"I'm not including the diffstat, because it got blown up by the resurrection of the sk98lin driver - because skge that is supposed to supplant it doesn't handle some of the hardware. Oh well.
"Apart from that, we had some mips, powerpc and xtense updates, and various driver tweaks. Things like the USB autosuspend revert should make people happier, and some more clockevents fixes should help suspend/restore on i386."
When the data corruption bug which is fixed as of 2.6.20-rc3 [story] was still being tracked down [story], it was thought that the bug, a race in shared mmap'ed page writeback, might have been in the 2.6 kernel for a very long time. It has since been determined that the bug was introduced much more recently. Nick Piggin [interview] explains, "this bug was only introduced in 2.6.19, due to a change that caused pte dirty bits to be discarded without a subsequent set_page_dirty() (nowhere else in the kernel should have done this)." Linus Torvalds noted that earlier kernels could have been affected by a less serious version of the bug:
"Actually, I think 2.6.18 may have a subtle variation on it. But that much older race would only trigger on SMP (or possibly UP with preempt). And I haven't actually thought about it that much, so I could be full of crap. But I don't see anything that protects against it: we may hold the page lock, but since the code that marks things _dirty_ doesn't necessarily always hold it, that doesn't help us. And we may hold the 'private_lock', but we drop it before we do the dirty bit clearing, and in fact on UP+PREEMPT that very dropping could cause an active preemption to take place, so.. I dunno. For older kernels? If there is a race there, it must be pretty damn hard to hit in practice (and it must have been there for a looong time), so trying to fix it is possibly as likely to cause problems as it migh to fix them."
David Miller pointed out that some of the confusion as to when the bug was actually introduced comes from the fact that the original bug was against a 2.6.18 Debian kernel. Andrew Morton [interview] explained, "that was 2.6.18+debian-added-dirty-page-tracking-patches," then went on to caution that the fix still does not address a newly reported and currently unconfirmed BerkeleyDB corruption bug, "I'll assert (and emphasise) that the cause of the alleged BerkeleyDB corruption is not known at this time. The post-2.6.19 'fix' might make it go away. But if it does, we do not know why, and it might still be there, only harder to hit."
Linus Torvalds announced the release of the 2.6.18 Linux kernel, following the previous stable kernel release by three months [story]. He exclaimed, "she's good to go, hoist anchor!", the second year in a row that a kernel release has coincided with 'Talk Like A Pirate Day' [story]. "Here's some real booty for all you land-lubbers," Linus continued, "there's not too many changes, with t'bulk of the patch bein' defconfig updates, but the shortlog at the aft of this here email describes the details if you care, you scurvy dogs." In keeping with the theme, he signed the announcement, "Linus 'but you can call me Cap'n'".
The latest kernel source can be downloaded from your nearest Linux Kernel archive mirror [story]. You can browse through all the changes using the gitweb interface, complete with a 2.6.18 tag playfully declaring, "Raise the Jolly Roger!".
With the release of the 2.6.18-rc3-mm1 kernel, Andrew Morton [interview] included a brief note stating, "fwiw, I recently took a position with Google." He then linked to a Linux Today article which details the reasons behind his recent move. The article begins, "Andrew Morton has started working for a new company, but his day job as the Linux 2.6 kernel maintainer will remain exactly the same." In the article, Andrew discusses one of the reasons Google was a good fit, "in my position as kernel maintainer I feel that I should not be employed by a company which has a direct interest in the kernel.org kernel because this would put me in a position of making decisions which are commercially significant to my employer's competitors. As Google maintains their own kernel variant for internal use, their interests are largely decoupled from what happens in the kernel.org kernel."
Linux creator Linus Torvalds announced the first release candidate for the upcoming 2.6.18 kernel, "the merge window for 2.6.18 is closed, and -rc1 is out there". He noted that the changes are extensive, "the changes are too big for the mailing list, even just the shortlog. As usual, lots of stuff happened. Most architectures got updated, ACPI updates, networking, SCSI and sound, IDE, infiniband, input, DVB etc etc etc." Find the shortlog here. Linus went on described additional changes:
"There's also a fair amount of basic infrastructure updates here, with things like the generic IRQ layer, the lockdep (oh, and priority-inheritance mutex support) stuff by Ingo &co, some generic timekeeping infrastructure ('clocksource') stuff, memory hotplug (and page migration) support, etc etc."
Andrew Morton [interview] posted an overview of patches in -mm, discussing what is destined for inclusion in the upcoming 2.6.18 Linux kernel. He noted, "there is an unusually large amount of difficult material here." Patch sets that were discussed include a cleanup of kernel headers, klibc, various subsystem cleanups, the ACX1xx wireless driver, swsup cleanups, per-task statistic metrics, a clocksource management infrastructure, smpnice, swap prefetching [story], priority-inheriting futexes, a revamp of /proc/pid, ecryptfs, utsname virtualization [story], readahead, reiser4 improvements, a statistics infrastructure, and lock validation code.
Following up on a couple of features discussed earlier on KernelTrap, both swap-prefetching and utsname virtualization were briefly discussed. In regards to swap-prefetching Andrew noted, "I remain skeptical, but I have a lot of RAM. Multiple people have sung its praises. I guess I'll re-review and tentatively plan on sending them along or 2.6.18. Opinions are sought." As for utsname virtualization, "this doesn't seem very pointful as a standalone thing. That's a general problem with infrastructural work for a very large new feature. So probably I'll continue to babysit these patches, unless someone can identify a decent reason why mainline needs this work. I don't want to carry an ever-growing stream of OS-virtualisation groundwork patches for ever and ever so if we're going to do this thing... faster, please."
