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

Comments

I'm posting this on top of 2.5.74

[Genyin]

In fact, 2.5 isn't that bad right now... certainly, it would be crazy to use it on a production system unless you really know what you're doing[1], but it's quite usable, and the scheduling has really improved.

[1] in which case you probably wouldn't use it on said production system... ;)

Re:I'm posting this on top of 2.5.74

[tuba_dude]

I've been using the various revisions of the 2.5 series for a few months now. You would not believe how much more responsive X is. Well, you might, but that's not the point. ;) It's been great, disk i/o is a bit faster, and the only problems I've had were with binary-only drivers.

probably, yeah.

[pb]

Even the regular Gentoo kernel has a lot of extra patches in it, including the O(1) Scheduler, and Low-latency scheduling; works great for me.

Re:What have I got to look forward to?

[bethane]

Being a LKML lurker, here are a few of the new features.

In-kernel Module Loader and Unified parameter support: http://www.kernel.org/pub/linux/kernel/people/rust y/patches/Module/

Nanosecond Time Patch: http://www.ussg.iu.edu/hypermail/linux/kernel/0210 .3/0793.html

Fbdev Rewrite: http://www.uwsg.iu.edu/hypermail/linux/kernel/0111 .3/1267.html

Linux Trace Trollkit (LTT): http://www.uwsg.iu.edu/hypermail/linux/kernel/0204 .1/0832.html

statfs64: http://marc.theaimsgroup.com/?l=linux-kernel&m=103 610918825614&w=2

POSIX Timer API: http://marc.theaimsgroup.com/?l=linux-kernel&m=103 553654329827&w=2

Shared Pagetable support: http://marc.theaimsgroup.com/?l=linux-kernel&m=103 498293902006&w=2

Hotplug CPU Removal Support and Kernel Probes

2.5.x

[bazik]

I am using a rock solid 2.5.70 since its released and its performs just great! And having Morton and Torvalds at OSDL is a good thing (tm) :)

Alan Cox on kernel 2.6

[k-hell]

KernelTrap is running a story on an interview Alan Cox gave at LinuxUser & Developer Expo 2003 in Birmingham, U.K. A summary of Alan's talk is also available.

New Name for New Linux

[Anonymous Coward]

not to be nitpicky or anything, but technically, shouldn't future versions of linux be referred to as GNU/SCO?

Re:What have I got to look forward to?

[mhesseltine]

Linux Trace Trollkit (LTT): http://www.uwsg.iu.edu/hypermail/linux/kernel/0204 .1/0832.html

I know it's a typo, but that would make slashdot much more interesting, wouldn't it?

Re:What have I got to look forward to?

[gotem]

more lines of code from SCO

Why 9 months?

[Gzip Christ]

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.

You might think that this was due to the birth of Linus' daughter Patricia. However, Linus actually spent those nine months cutting and pasting our code into the Linux kernel (there's so much of it, which is why it took him so long). Also, I am Patricia's real father.

-- Darl McBride

Question about 2.6 adoption by distros/maturity

[Apostata]

My question is this:

There was some hesitancy, upon the official release of kernel 2.4, based upon some bugs etc...

I'm wondering, does the kernel - generally speaking - get more and more stable. For example, will the first release of 2.6 be more stable than the first release of 2.4. I realise that there are new additions to the kernel, and with that new problems will probably emerge. However, comparatively speaking, does it make sense that the kernel's evolution will lean towards stability with each release in the cycle, or will it generally be unnoticable?

Just curious.

Re:Question about 2.6 adoption by distros/maturity

[XO]

2.4 actually had some fairly serious flaws in the middle of it, but the modifications that were done that caused those flaws were, imho, necessary for further evolution.

Certainly pre-2.6 should squash out most bugs, however !! remember the vast majority of Linux users out there are NOT likely playing with 2.5.x or will be with pre-2.6!

The stress tests that come from 2.6.0 being announced and suddenly being unleashed upon tens of thousands more users (or hundreds of thousands more machines) than 2.5.x is will shake out all remaining serious flaws.

Re:What have I got to look forward to?

[anshil]

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.

Re:Distro Upgrade?

[Vanieter]

I would tend to say you'd need to modify your apps so that they'll run correctly with the new ALSA interface for sound support - although it supports OSS/lite emulation pretty much perfectly (as far as I know of)

Also, modules names have (I think) changed, so a change in the init scripts would probably be useful. It depends on your distro though - I'd say distros like Slackware and Debian will have guides or automated tools for migration. Commercial distributions will probably have to release a new version (RedHat 10 ? Gods).

Although maybe I'm wrong, I never managed to get a working 2.5.x kernel on my Debian box =)

Re:Microsoft leads the way with SP4 for Windows 20

[be-fan]

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.

not a day too soon

[Trepidity]

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.

Re:Distro Upgrade?

[Genyin]

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.

Re:What have I got to look forward to?

[bartc]

Here's a nice overview by Guillaume Boissiere:

http://www.kernelnewbies.org/status/latest.html

And a document by Dave Jones:

http://www.codemonkey.org.uk/post-halloween-2.5.tx t

Re:Should I get excited over any of these features

[xenocide2]

Well, the nanosecond patch is critical for make on fast computers, since it uses filesystem timestamps. If you're running gentoo on a brand new desktop it might be a good idea.

The fbdev patch reduces the size of the framebuffer, so if you like framebuffered consoles, it will reduce your kernel size.

If you have multiple processors, the Shared page table patch will help reduce page table sizes, and thereby improve performance, marginally. More RAM = more file cache / less disk paging; shared data -> higher cache coherency = faster kernel performance in memory mapping.

Additionally there seems to have been some mucking around with tweaking the adaptive scheduler so X gets more time when it needs it. The performance metrics have been kind of squishy, but the general consensus is that X and related 'interactive' processes are more responsive.

2.6 isn't a production version

[ceswiedler]

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.

Re:2.6 isn't a production version

[iabervon]

That's why there's going to be a substantial 2.6-pre series, and why Andrew Morton is going to be the one to release 2.6.0. The goal is for 2.6.0 to be a production release, which means that 2.6.0 can't be the first 2.6 kernel. Fortunately, kernel versioning supports the creation of 2.6 kernels which are before 2.6.0, and Linus understands that his skills are not in release management.

The real step needed for stability is testing by a wide variety of people. This should actually be easier to get than in the past, since a much larger portion of the front-line testing these days is done by the various distributions, who are not getting into the "enterprise software" business, where they have to do substantial research on whether the software works on different systems before releasing it. And distributions are generally a lot closer to the development process than random individual users are, so they can be more easily convinced to start testing a stable series in advance of the .0 release. Furthermore, there's a lot more testing and verification infrastructure these days than in the past, from the Stanford checker (which catches a lot of unsafe usages in obscure drivers without having the hardware necessary to actually run them) to various test labs.

There's actually quite a bit more effort put into making sure that end users get a stable kernel these days than in the past, as more business software companies promote Linux more heavily. IBM will make sure that they know at all times the status of 2.6 kernels with respect to any bugs that can be triggered on any of the hardware IBM ships, and they'll make sure that Linus and Andrew know whether a kernel is suitable for 2.6.0, at least from IBM's perspective.

The real question is whether Linus will manage to hold off starting the 2.7 series until 2.6.0 is released. (Personally, I doubt it; I bet Linus will want to release 2.6.0 before Andrew is willing to, and I bet Linus will decide that the current version may not be good enough for production, but it is good enough to start further development, and Andrew will agree that people who want to work on 2.7 aren't going to do anything more useful for the remaining 2.6 problems at that point)

Reiserfs

[Anonymous Coward]

I'm sure I'm not the only one who's wondering if Reiser 4 will go into the stock 2.6! So: does anyone know?

Re:Reiserfs

[LarryRiedel]

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.

Larry

Re:Road trip, here comes memory lane

[tuba_dude]

Tell us more grandpa! Tell us about the time you wrestled and maintained 8 AIX servers single-handedly from your homebuilt Linux box! Or about the time Linus got lost and asked you for directions and you went on a whirlwind big-city adventure!

Re:Oh yeah? Well, I'm on 2.5.75, buddy!

[ghum]

t my mouse speed in gnome was sped up by about 10x over 2.4

great news! 900% speedup from Linux kernel 2.4 to 2.5.75

Re:load kernel from kernel?

[Daniel Phillips]

"What about that? Will we be finaly able to switch kernels without a reboot?"

I did that back in the 2.2 days with monte. Later with 2.4 kernels I did a few changes, added a feature I was missing, fixed a bug and such stuff. In case you want to see it. But it was never completely stable and lacked SMP support.

kexec might be a better alternative. AFAIK it is being maintained and might even have made it into the 2.5 kernel.

It was only a couple of years ago that knowledgeable people were calling this idea ridiculous, and giving good reasons, however progress has marched on, and we're actually coming within sight of it. The basic challenges are much the same as for hotplug cpus, hotplug memory, process migration in a cluster, and yes, kexec, all of which are being worked on or already working. So I'll go out on a limb and predict that hot-kernel swapping will be demonstrated during the 2.7 timeframe. It won't be perfect, but such things never are in the first cut.

The thing that makes hot kernel swapping practical is the stable api between userland and the kernel. Big changes there are few and far between, and they can be special-cased.

Re:What the heck?!

[darc]

I recommend "Ask slashdot (http://ask.slashdot.org)", which is sort of a newbie forum for stupid questions that can be solved with google. So, like, post all your issues, such as:

"How do I mod my xbox"
"Should I overclock my CPU"
"How do I make everything more faster"
and,
"This question is just begging to have all replies start with IANAL"

Join the club!

IDE Layer Rewrite

[zoward]

I've been hearing though other channels that the IDE layer rewrite improves the IDE subsystem to the point where SCSI emulation won't be needed to drive an IDE CD burner. Can anyone confirm or deny this? If so, this will probably become my main reason to switch to 2.6 (although there are quite a few secondary ones too). Thanks linux team (and IDE rewrite folks)!

Nothing to do with IDE rewrite

[axboe]

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