Slashdot Mirror
New Kernel 2.4 Development Branch (-mjc)
Ivo writes: "kerneltrap is reporting: Michael Cohen announced to the lkml his intention to begin a new 2.4 development tree. The first release of his -mjc branch includes a number of performance enhancing patches, including Robert Love's preemptible kernel patch, Rick van Riel's reverse mapping patch and George Anzinger's real time scheduler patch. Michael says of this patch, "I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go. Feel free to test it""
Most of the performace patches (pre-emptible, etc) are just patches to the current kernels that the stable kernel's maintainer hasn't accepted, for one reason or another. Chances are, they will go straight into 2.5 so that they can be tested and improved upon.
The reason for -mjc is to allow people to use the performance patches without having to worry about conflicts between the patches, applying them, etc - it looks just like a normal kernel package, except with -mjc at the end.
The -ac series follows the same guidelines - it tends to have slightly fancier features, newer drivers, etc. Every once in a while, when the stable kernel's maintainer decides that the -ac series is stable enough, a lot of the patches that went into -ac are put into the stable series, to get all the new drivers in there.
I doubt that will happen the same way for -mjc, since the patches are more along the lines of getting every little bit of performance possible, instead of having a wide testing ground for new drivers, vm's, etc.
I'm glad you're happy with BSD, but really you could have had the same thing by ignoring the various development trees and optional components and sticking with a distribution you like.
This is, of course, crap.
Here's a real-world example. The story began early last year. I had a spare PC with USB at the office, so I thought I'd put a couple of Keyspan USB-Serial adapters on it, load Red Hat 7.1, and use it as a console server for our SGI Origins.
Standard Pentium III PC-- no unsupported parts in it. GeForce2 graphics card, but I had no intention of installing X anyway, so minimal support is all that's required. The Keyspan USA-49W serial adapter is, according to the source tree, to Red Hat, and to Keyspan, supported completely under Linux 2.4. I felt pretty safe.
I don't enjoy messing with Linux, but I do prefer XFS to EFS for several reasons, so I thought I'd try SGI's modified Red Hat 7.1 installer that supports XFS. It installed a 2.4.3 (I think) kernel, which wasn't too far behind at that time. I'd used that installer before, so I felt safe with that, too.
I installed the OS, then I put the Keyspans on. They didn't work. Why not? Despite the fact that the Keyspan driver had been installed as a module with the Red Hat default install, it had been compiled with no firmware in it. So I had to load the sources, load the compiler, and recompile the kernel modules to add Keyspan firmware support.
Then I installed the new module and found that one of my Keyspans was working, but not the other. Turns out whichever one was plugged in first worked, but the subsequent ones wouldn't. Driver problem.
Frustrated, I gave up for the weekend and didn't touch the system again for several months.
Earlier this fall, I happened upon a mention of this bug being fixed in the Keyspan driver. Cool. So I downloaded the latest Keyspan driver source and put it on my machine and rebuilt modules. Only the new Keyspan sources wouldn't even compile. I'm sorry that I don't remember the error, but it had to do with the layout of a struct. The 2.4.3 source tree had a different struct than the Keyspan driver expected.
(An aside: it has always been my understanding that minor version changes must not introduce incompatibilities. I mean, that's what 2.5 is for, right? To have a data structure that's laid out one way in 2.4.3 and another, incompatible way in 2.4.9 strikes me as just wrong. End of aside.)
By that time, I thought I understood my problem. I would dump Red Hat with XFS and install vanilla Red Hat 7.1, then install the latest kernel sources and compiler, then install the new Keyspan sources, then compile the module, then it'd work.
Well, it didn't quite work that way, either. What with one thing and another, I was unable to get a working kernel.
Again, I gave up for a few months.
Then SGI released their modified Red Hat 7.2 installer, with a 2.4.9 kernel, so I decided to try just one more time. Install Red Hat 7.2 with XFS, install the sources, install the compiler, install the new Keyspan sources, make the module.
Success.
So I got my system working the way I want it to work, and I'm now very happy with it. But it took me three long weekends, spaced out over several months, and three start-over-from-scratch attempts.
I'm frustrated that Red Hat decided to include the firmwareless version of the Keyspan driver, since it would have been so much simpler to just compile the firmware into the module so it would work out of the box. I'm disappointed that the person who maintains the Keyspan driver was unable to QA his work sufficiently to prevent the only-one-adapter bug from hitting the streets. And I'm mad that a driver module should compile cleanly only under 2.4.9 or later, but not earlier versions. That's not the right way to maintain an OS.
Sorry for the overlong post, but your contention that the distributions are out-of-the-box solutions is just plain wrong.