Slashdot Mirror
Linus Says Pre-2.6 is Coming
gomoX writes "As seen on C|Net , Linus has announced that the pre-2.6 series will be starting in early July. Despite not having been able to meet the release goal for 2.6 in June 2003, the next stable version is not as far away as you may think. You can take your guess based on the fact there was a 9 month period between first test version of 2.4 and the official release of 2.4.0 on January 2001."
Being a LKML lurker, here are a few of the new features.
t y/patches/Module/
0 .3/0793.html
1 .3/1267.html
4 .1/0832.html
3 610918825614&w=2
3 553654329827&w=2
3 498293902006&w=2
In-kernel Module Loader and Unified parameter support: http://www.kernel.org/pub/linux/kernel/people/rus
Nanosecond Time Patch: http://www.ussg.iu.edu/hypermail/linux/kernel/021
Fbdev Rewrite: http://www.uwsg.iu.edu/hypermail/linux/kernel/011
Linux Trace Trollkit (LTT): http://www.uwsg.iu.edu/hypermail/linux/kernel/020
statfs64: http://marc.theaimsgroup.com/?l=linux-kernel&m=10
POSIX Timer API: http://marc.theaimsgroup.com/?l=linux-kernel&m=10
Shared Pagetable support: http://marc.theaimsgroup.com/?l=linux-kernel&m=10
Hotplug CPU Removal Support and Kernel Probes
Bethanie: Whore...
Fan Whore
not to be nitpicky or anything, but technically, shouldn't future versions of linux be referred to as GNU/SCO?
I know it's a typo, but that would make slashdot much more interesting, wouldn't it?
Overrated / Underrated : Moderation
more lines of code from SCO
-- Darl McBride
I think for me most important the ALSA sound system is finally part of the linus kernel. Meaning you do not need to patch the kernel anymore to get recent sound support.
--
Karma 50, and all I got was this lousy T-Shirt.
The Windows kernel hasn't changed significantly since the NT4 -> Win2K change. The biggest improvement in the XP kernel was pre-faulting the pages of large processes. Meanwhile, in 2.6, the block I/O layer, VM layer, scheduler, and sound system are brand new. And the whole kernel was made preemptible! Shortly after 2.6, ReiserFS 4 (which looks very promising from initial benchmarks) will be released. In all, 2.4 -> 2.6 will be like NT4 -> XP!
PS> Before anyone bitches about rewrites being a bad thing, look at things this way. Such extensive changes are necessary for the continually growing range of systems Linux is expected to run on. 2.0 and 2.2 were greatfor single CPU servers, or SMP machines with only a few processors. 2.4 is very usable for heavy-duty machines with many more processors. 2.6 (along with the changes that help interactivity) will make an excellent kernel for desktop machines and workstations. In 2.8, the focus will be on optimizing the core algorithms to run on large-scale NUMA machines.
A deep unwavering belief is a sure sign you're missing something...
It'll be nice when it finally comes out, because I'll be able to point people doing audio work to Linux. Right now I have to say "well, Linux is better than Windows for this, but only if you apply the low-latency, pre-emptible kernel, and variable HZ (with HZ set to 1000) patches," which is a bit more involved than most people who are just doing audio work want to deal with. Once 2.6.x comes out I can just point them to the stock kernel.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Also, the old OSS modules are still in the kernel. I haven't tried them in 2.5, and they are marked with a big DEPRECATED, but they're still there.
Note, of course, as I've said elsewhere, you do need the new module-init-tools; I'd imagine that would be the most likey reason you'd have trouble getting a 2.5 kernel working, followed closely by an out of date/broken driver.
There's a lot of complaining about code-freezes for the kernel not being code-freezes. People gripe about major changes being introduced in the last days of the development version.
I think the problem is the standard explanation of 'even kernels are production, odd kernels are development.' Whether he says so or not, it's clear that branching to an even version does not mean that it's a production kernel...branching to an even version begins the code freeze. Up until they call it 2.6, there's going to be large changes to the codebase. Once Linus calls it 2.6, everyone knows they can't put in major changes, but basic bug-fixes only. Therefore, it's never until a few months (or a year) after the even series starts that it's really a production kernel.
Software development managers would hate this...lots of kernel developers hate this...but love him or leave him, that's how Linus works.
I think it is safe to say nobody knows if Reiser4 will go into the stock 2.6 kernel, but I think the principals would like it to happen, and depending on how well the Reiser4 beta performs this summer, it should be possible, as long as it does not appear that adding the Reiser4 code would disrupt existing code.
LarryYou are correct in assuming you don't need ide-scsi to emulate a SCSI host for burning cdroms in 2.6, but it has nothing at all to do with the IDE rewrite.
2.6 has support for queueing "generic scsi" commands through the block layer, using the same mechanism and transport as the regular read/write file system requests. So we can overload the sg (scsi generic) SG_IO and provide the same functionality for non-scsi attached devices (such as atapi burners). With a recent cdrecord, you can give the device with -dev=/dev/hdc for instance.
Additionally, cd burning is now zero copy. The user space data buffer is mapped directly into the kernel for the dma operations. DMA is supported on a 4-byte boundary, where 2.4 and previous has required sector alignment (512 bytes) for any atapi dma operations.