Slashdot Mirror
What Happens To -AC (And Other) Kernel Mods?
Note: Here's what Alan passed on in response to this question. As usual, things aren't quite as simple as they first appear. -T.
Alan Cox: Probably the first thing to explain is the Red Hat kernel. That actually isn't something I am responsible for. Arjan van de Ven is the keeper of the distribution kernel, and has the unenviable task of getting a kernel together that will actually pass all the brutal QA testing. Arjan is perfectly entitled to (and sometimes does) throw out bits of -ac changes.
You'll see Red Hat patches being merged into -ac and Linus trees when appropriate, often from Arjan or Pete Zaitcev. Many of the other patches in the RH tree are considered "fixups" - they are workarounds for problems but not generalised or clean enough to feed into the main tree without further work. Others are RH specific patches for things like packaging.
With the -ac tree I try and do rapid rolling releases, sucking in new code to test it and also its interactions with other new code. By doing releases every few days I get a high number of people testing and reporting bugs before there are too many possible causes. This is how Linus trees used to work long ago, and I still think its the better technique.
At regular intervals I take stuff from the -ac tree and feed it to Linus. Sometimes Linus doesn't want to take other changes in case they confuse other things being done, sometimes they just vanish and fairly often they get applied.
I'm actually limited in the rate I can forward patches because I need to feed Linus blocks that are debuggable. Thus I don't want to feed Linus both file system and disk driver changes at once or I won't know which to blame if there are corruption reports.
I also don't feed Linus code that has active maintainers unless the maintainer has asked me to do so. Thus the USB diverges quite a lot because Johannes Erdfelt has chosen not to feed chunks of the USB and input changes on. Similarly, the user-mode-linux port in -ac has not been fed on to Linus because Jeff Dike wishes to improve it further before submitting it.
I have been concentrating on getting the driver code and some architectures synchronized with Linus, and that is now mostly done. The next big challenge is getting all the file system work on to Linus, and Al Viro has begun that and fed Linus the first blocks of the superblock handling cleanup.
Finally we have changes that are down to fundamental disagreements, perhaps in part stemming from the fact my background is real production systems rather than OS design work. Linus decided to update the 3D support without keeping back compatibility - I kept both. Linus I suspect will never accept a patch to do that. Secondly he decided that he didn't wish to allocate new device major numbers but look for a saner solution over time. Laudible, but not in the middle of a stable release. The -ac tree has drivers allocated "non-Linus" major numbers that are recognized by LANANA and thus common across vendors. These drivers like the HPT370 and Promise IDE raid will thus always be part of the -ac tree only.
The -ac tree also tries hard to avoid any incompatibilities. Having applications that require -ac or Linus trees is simply not an acceptable situation. The only specific exception for that right now for 2.4.x is deep at the system level and is for quota tools. That one was unavoidable to get 32bit uid quota working.
One thing that's been in the -ac kernels for quite some time is the ability to post-mortem debug multithreaded processes. That is, under the production kernel, when you core dump, all the threading information is lost. You can't get the call stack of each thread. With the -ac kernels you got one core file per pid, with each LWP (lightweight process) getting its' own core file.
Considering that Solaris has had this (what seems to be BASIC) functionality for years, why do we see the continued insistence on keeping this functionality out of the production kernel? Are we waiting for the gdb team to catch up?
Until this is fixed, multithreaded programming under Linux will remain a black art - only developers willing to apply hordes of -ac patches to a homegrown development kernel have a change of successfully developing a multi-threaded application under Linux. Considering that many commercial software development packages (RogueWave, for instance) won't even support you if you're not using a RedHat released kernel, this puts multi-threaded development "out-of-bounds" for many.
Merge the -ac kernel mods!
Max OS X has this feature as well. If you set CRASHDEBUG=-YES- in /etc/hostconfig, you will get a dump of all thread stacks and the CPU(s) registers when a process bombs out. Very handy. I believe that HP-UX also has this feature. Surprising that Linux doesn't.
In case anyones wondering 'cyfrifiadurol' isn't a typo. It's Welsh roughly meaning 'to do with computers'.
And before anyone says it, yes, computers have reached Wales now...
You make an assumption that the right way to test code is in big lumps. That is somethiny any engineer will tell you is bogus.
You test continually, you test each changeset, and then every so often you run a several day shakedown test.
You are right that you can't QA a kernel to vendor production grade in two weeks. Some of the RH test runs take several days per run for example.
The goal there is to make it unneccessary. 2.4.8-ac7/ac8 have slightly smarter VM merging behaviour done by Ben LaHaise for example.
That's one of the reasons I started that project, in the first place. Because it's mind-numbingly tedious to massage patches from different groups together. If you can get the whole thing in one gigantic gloopy splodge, life would be much easier.
Unfortunately, I've discovered a number of things along the way:
That's not to say that FOLK is a disaster. Quite the opposite! I'm learning a huge amount about the Linux kernel, for a start, and the sheer complexity of juggling hundreds of patches is really giving my C coding skills a workout and a half!
My hat is off to Alan Cox who not only manages his patch set with far more grace than I ever could, but actually keeps it so that it runs!
I know the Royal Web Admin uses Linux (cos that was on an interview, some time ago), so if he's reading & has any influence, I honestly think Sir Cox would not be an undeserved title for his amazing computing skills and his contribution to both computing and Britain.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The Promise RAID *is* software RAID. All the kernel can give you is access to the extra IDE ports (which is does).
In the mean time, if you're desperate, I can give you a patch that provides this capability to any Linus tree.
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
What Happens To -AC (And Other) Kernel Mods?
I'm sorry, but if the kernel has a bunch of modifications done by people who find it necessary to be referred to as the initials for Anonymous Coward then how can we trust the security of the kernel?
They get modded down on /. but then get merged into the kernel source? Let's make a stand and stick to it!
Oh, and I copied these comments to a text file so I can repost it in the event that /. pukes up it's guts again.