The Must-Fix List For 2.6.0

Jeremy Andrews writes "Andrew Morton posted a lengthy list of items that need to be done before the 2.5 development kernel tree should be turned into the 2.6 stable kernel tree. He prefaced his list by noting that 2.6.0 does not mean, "it's finished, ship it", alternatively offering, "I'd propose that 2.6.0 means that users can migrate from 2.4.x with a good expectation that everything which they were using in 2.4 will continue to work, and that the kernel doesn't crash, doesn't munch their data and doesn't run like a dog. Other definitions are welcome.""

Comments

You don't say

[Otter]

I'd propose that 2.6.0 means that users can migrate from 2.4.x with a good expectation that everything which they were using in 2.4 will continue to work, and that the kernel doesn't crash, doesn't munch their data and doesn't run like a dog.

Actually, accomplishing that would exceed the expectations I've evolved for 2.4.x. (That's the great thing about Linux performance -- if you don't like the VM, wait a day and it will change.)

Great!

[4of12]

I'm all in favor of these things getting fixed so I can run the new 2.6 kernel.

Any, uh, realistics care to venture when all this might be done?

aww, nuts

[Khopesh]

so this isn't going to be Linux Kernel 3.0
(as previously reported on slashdot back in september)

Re:aww, nuts

[FroMan]

What is people's hang up with 3.0? It will be that exact same code, except uname -v (do I remember the command line options?) will report 2.6.0 instead of 3.0.0.

2.4 will be known as "the kernel that sucked"

[Anonymous Coward]

Testify, brother!

We keep trying to go to 2.4, and end up back at good ol' 2.2 every time.

Most of our NFS infrastructure cannot be made to run under 2.4, and the scsi drivers (especially adaptec) suck (because they are poorly rewritten 2.2 drivers) and many of the network device drivers (such as, TG3) are so poorly written they will lock up your machine completely in a packet storm. Or, alternatively, they will create a packet storm.

I'm posting this anonymously because Alan's already mad enough at my whining and complaining.

It's free software. Use 2.2 until something better (maybe 2.6, maybe the mythical 3.0, maybe the Hurd) evolves.

More lazy editors

[fm6]

Come on guys. I only had to stare at this story for a couple of seconds before I figured out that you're talking about the Linux kernel. But I shouldn't have to! Stop being so lazy!

Re:More lazy editors

[Otter]

In their defense -- the WSJ just pointed out this story about Fareed Zakaria:

Left-Of-Bush Brain Curry Man

Makes even Hemos' most astonishing efforts look lucid.

Fix the token ring card support!!!

[mnmn]

Until I realize I am the only one around with the biggest pile of tokenring cards and hubs for testing. Maybe in the summer vacation, I could work on some of the code, and try fixing the receive buffer problems. This is assuming I'm a better programmer by then.

I hope the rest of the kernel is stable as hell by the release time. Most geeks in their homes with x86 clones dont need more functionality, we need stability that kicks Solaris and BSD.

Re:Fix the token ring card support!!!

[MartinG]

Just out of interest, what problems are you getting?
I've been using linux with token ring daily for years without problems. I'm using a pcmcia IBM 16/4 card at the moment, but I had a pci ibm card before also with no problems.
Initially, I was using an IBM lanstreamer (about 2 years or more ago), and I had occasional problems with that under heavy network load. It would just stop working, although the kernel didn't seem to think anything was wrong. "ifconfig down" followed by "ifconfig up" would usually fix it, but sometimes oopsed. I attempted to debug it once but got lost.

Start Now

[MBCook]

I've been running various versions of 2.5 for a while now. You need to make sure you have the new module utils installed, but otherwise just use it! I haven't had any problems with it (other than it can be a bit of a pain to get the nVidia binary drivers working, but it's not that bad). I think the performance is better. But if you can (IE you don't need hardware that doesn't currently work) then I'd suggest you use it.

2.5.68 (my first "odd-numbered" Linux kernel)

[Dr. Photo]

Yesterday I cooked up a 2.5.68 development kernel (the latest beta version as of this writing, according to kernel.org), since it has a fix for my newer chipset (damn VIA and their nonstandard AGP GART...), though I suspect that, depending on whether mine uses agp2 or agp3 I might be able to trick a stable kernel into playing nicely with it (assuming it's just a matter of model number, in which case agp_try_unsupported=1 comes to the rescue.)

My impression of the development kernel (aside from nice new features and not needing to 'make dep' anymore) is that it seems to be just a little bugfixin' away from being "ready"... and desktop users will appreciate the fact that ALSA seems to be in the kernel proper now, instead of being something to tack on the side afterwards.

The Linux Information Minister

[Anonymous Coward]

Things we should not track here are:

- Regular old bugs. Please use bugzilla.

- Wishlist items. This list is not a route for getting commitment for inclusion of $FAVEFEATURE. In fact it's probably a good way of getting the feature shot down ;)

- Driver problems. Most important drivers mostly work OK now. Please use bugzilla.

So, these are all the things that should be fixed in 2.6, except the things that are broke, the things you want, and the things that don't work.

Not only that, if you do ask, they definately won't fix it. Love that open source.

Re:The Linux Information Minister

[mabhatter654]

They want a list of things to finish, not start!
Regular bugs and driver bugs are other people's departments. This list is for the Choosen Few who can actually write kernel code. I'm kinda surprised they even posted it here where all the idiots can harass those poor souls. Of course Wishlist items were out a while ago at feature freeze--again, don't waste their time-someone already decided what was in and what was out. They're looking for heavy duty programming that needs done. Systems to toss out and rewrite just because it won't work anymore. Bug fixes that have Fscked the system. Not petty requests from us!

It's a huge project. I mean they have to keep up with 2.4 patches, then adapt all the 2.4 things to 2.5 along the way, then add new features that break a bunch of stuff, then fix what they broke, then try to optimize things for stability and speed, then rewrite it because it's hosed, fix more stuff they broke...etc. It's a vicious cycle and few people in the world can do it!

So stop Whineing!

but uhm

[nocomment]

I'd propose that 2.6.0 means that users can migrate from 2.4.x with a good expectation that everything which they were using in 2.4 will continue to work, and that the kernel doesn't crash, doesn't munch their data and doesn't run like a dog..."

Shouldn't we wait till the 2.4.x branch does that?

Re:but uhm

[Anonymous Coward]

It's a good thing I don't have mod points right now, because I wouldn't know how to handle your post. It's clearly Flamebait, but it's also Funny.

Regarding stability, I'm going to wait until at least 2.6.5 (give or take) before I upgrade my desktop machine. I like features, but I like stability more. For what it's worth (nothing), 2.4.20 has been quite stable for me, except that something on my computer leaks memory like a sieve (I'm guessing the binary nVidia drivers, but I'm not sure), so I have to reboot at least once a week, which is very annoying.

Re:but uhm

[bobbozzo]

You should be able to check that by unloading and re-loading the driver modules to see if the memory is freed.

Another culprit might be the X server.

Direct IO

[Alastair]

I'm not sure if this has been addressed in 2.5 yet, so apologies if it has.

Many thanks to Andrew for all his work, especially with ext2/ext3 (but much more I know). I'd like him to consider making sure that direct IO is properly working in 2.5 (and 2.4 for that matter). In particular ;

a) Support in ext3.

He posted a patch to the kernel list that added this, which I tested and it seems to work. It would be good if this is in the 2.4 and 2.6 kernel.

http://www.geocrawler.com/mail/msg.php3?msg_id=932 9947&list=7493

b) Correct functionality for non-4K multiple reads in ext2/ext3

i.e. less than 4K read as a remainder at the end of file. Again, Andrew posted a patch for this on the kernel list, and it seems to work. This is relevant for a) as well it seems.

http://marc.theaimsgroup.com/?l=linux-kernel&m=104 515769523283&w=2

Apart from that, all the stuff we need to make sure we can read and write as fast as possible to disk or RAID would be great. I need at least 300 MB/sec (PCI-X, U320 SCSI bus x2) but the more the better :-)

Keep up the great work!

These aren't "must-fix", but...

[jd]

I estimate that there are about 5-10 megabytes worth of patches which I would put in the "important standards" category.

There are probably about as many that I'd place in the "extremely useful & wanted by industry" category. The "lustre" filesystem would be in that category, for scalability, which IBM, et al, are positively screaming for.

There are probably about twice the above two combined in the category of "improves compatibility with other OS'". The port of Sun's Doors IPC system to Linux is one example. STP (Scheduled Transfer Protocol), from SGI, is another.

The practical reality is that you can't add them all. I know, cos I've tried, and the result is horribly unstable. I'm going to resume work on FOLK, asap, but I'm going to use the Linux Kernel testing code to develop a validation suite. It'll mean that patches won't match the author's version, but it should make FOLK a good deal more robust. (Besides, the main reason for using FOLK is to see how crazy the configuration menu has become. :)

So, what am I saying? I'm saying that either some need to be in 2.6.x, and others added in 2.7.x, OR you need to add the bulk of these in 2.7.x.

The bottom line is that there's a lot of really important code that Linux needs, if it's to retain the crown as Standards King. The more lax we become in adding this code, the more the mainstream industry will stick to existing, closed-source solutions. Why switch to something that adds nothing? (From their perspective, that is.)

Linux is an amazing OS - the 5th fastest supercomputer in the world runs on it! Try that with any other mainstream OS! Its growth has been exponential and looks set to stay over that critical linear level for some time... ...but that's only going to happen if Linux is perceived as something truly remarkable by current NON-users.

So far, much of what I've seen in 2.6.0 is great - for EXISTING users, but really doesn't offer any new strong incentive to those yet to take the Linux plunge. Hey, there's nothing wrong with the old incentives, but if you want to continue with the exponential growth curve, you've got to keep adding new compelling reasons why Linux would be worth the time, money and effort of switching to.