Weekly Edition
Return to the Kernel pageRecent Features
| |||||||||||||
Kernel release status
The current 2.6 kernel is 2.6.9, released, at last on October 18. Very
few fixes were merged since 2.6.9-final,
which, in turn, contained only a small number of changes since 2.6.9-rc4.
The -final naming scheme drew a few complaints, to which Linus responded
"I'm a retard." One assumes he will not do that again.
For those just tuning in, 2.6.9 includes a lot of NTFS updates, block I/O barrier support, a patch allowing unprivileged process to lock small amounts of memory in RAM, a new USB storage driver, cluster-wide file locking infrastructure, completely out-of-line spinlocks, AMD dual-core support, support for the POSIX waitid() system call, KProbes, USB "on the go" support, the "flex mmap" user-space memory layout, m32r architecture support, a bunch of latency-reduction work, and lots of fixes. See the (lengthy) changelog for a full list of changes since 2.6.8. There have been no 2.6.10 prepatches released yet, but the floodgates have certainly opened; several hundred changesets have found their way into Linus's BitKeeper repository. These include a set of SCSI updates, a big rework of the IRQ subsystem (pulling lots of duplicated code into a single, generic core - no functional changes), some software suspend fixes, a number of scheduler tweaks, CDRW packet writing support, switchable and loadable I/O schedulers, a new version of the completely fair queueing (CFQ) I/O scheduler, the removal of the (unused) wake_up_all_sync() function, a simple generic circular buffer implementation, a big USB update, version 17 of the wireless extensions API, the kernel events notification mechanism, a patch changing the core device model function exports to GPL-only, a PCI subsystem update, the BSD "secure levels" security module, and lots of fixes. Andrew Morton has not released any -mm patches over the last week. The current 2.4 prepatch is still 2.4.28-pre4; Marcelo has not released any prepatches since October 8. (Log in to post comments)
Kernel release status Posted Oct 21, 2004 10:43 UTC (Thu) by smurf (subscriber, #17840) [Link] "several hundred". That's an understatement; my pull just now saw 1294 changesets containing 4595 changes.
That's ... quite a lot.
Kernel release status Posted Oct 21, 2004 12:01 UTC (Thu) by zezaz (guest, #5465) [Link] Just curious: what are the main differences between the new USB storage driver and the old one?
Kernel release status Posted Oct 21, 2004 20:53 UTC (Thu) by proski (subscriber, #104) [Link] From what I see, the new driver (drivers/block/ub.c) doesn't depend on SCSI and supports only a narrow class of devices, such as Olympus cameras. I cannot find any reason why this driver was written other than getting rid of the SCSI dependency.
Kernel release status Posted Oct 22, 2004 20:16 UTC (Fri) by zezaz (guest, #5465) [Link] Thank you for this response. This change seems interesting enough, AFAIR the same thing happened for ATAPI CD writing which got rid of the SCSI dependency in the 2.5.x series. Let us just hope that the compatibility will get broader again. And that Linux on an USB stick will become easier to handle after this change!
Kernel release - new development model? Posted Oct 21, 2004 13:06 UTC (Thu) by tjasper (subscriber, #4310) [Link] Posted this under the MODULE_PARAM section further down. Perhaps should have posted it here first...
This also relates to the other articles as part of the Linux kernel page. It seems to me that the kernel development model is morphing into an Andrew development/unstable kernel and a Linus stable kernel.
I guess, given the complexity of the kernel these days, that breaking off into a development series and then bringing it back to a stable series is getting to be harder and harder.
With a larger and more diverse code base is it perhaps, with small sections of development are going into Andrew's tree and stabilising and then being merged into the stable series, that a newer kernel development model is being forged now? This gets more up-to-date features out to users faster than the old cycle. For example, I'll bet that there was more code went into the 2.6.8 to 2.6.9 than went into the entire 1.1 or 1.3 trees? Yet this only waranted a dot.dot release now.
Is it time to do some conceptual blockbusting on the old development model, and not to expect a 2.7 series. Rather should we expect more and more development to go on in and upstream of the -mm trees, subsequently merged into mainline?
What then of version numbers? Should we consider the -mm to be the equivalent of a 2.7 series? Then 2.6.10 would be the equivalent of the 2.8 or 3.0? Perhaps, with the current model, a slight expansion of what actually gets into the -mm tree in terms of more radical development (such as Ingo's RT patches) get us back into the development vs stable series of old but in much more manageable sizes and keeps patch pressure down on the stable series, as it moves into each dot.dot release more quickly.
It seems/feels to me that 2.6 has evolved in small steps into something more like 2.8 without the big step change. Distributions seem to have an easier time of shipping dot.dot releases more regularly, and being much more up-to-date while they do it. It also gets many more users USING the latest releases which can only help code development.....
Trevor Jasper
Kernel release - new development model? Posted Oct 21, 2004 13:31 UTC (Thu) by mtk77 (guest, #6040) [Link] I guess, given the complexity of the kernel these days, that breaking off into a development series and then bringing it back to a stable series is getting to be harder and harder.If I'm not entirely mistaken, it's precilsely because bitkeeper makes it so easy to keep development and stable trees in sync that there's no pressing need for anything like a 2.7 at the moment.
Still no 2.7??? Posted Oct 21, 2004 15:15 UTC (Thu) by mmealman (guest, #9223) [Link] Is anyone else surprised that there still isn't a 2.7 kernel? I've seen changes in 2.6 that have broken things that worked in prior versions of the kernel. We need a 2.7 playground to test these changes more fully before they go into 2.6.
|
|||||||||||||