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!
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.
Perhaps he meant the unstable series Linus releases. I sure as hell would NOT like to see a new "stable" kernel release every few days. The current faux-schedule of a new release every couple of weeks seems a bit too quick for decent testing to me, to tell you the truth.
Interested in open source engine management for your Subaru?
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...
That their database is still Having Issues. We need a story on what's going on there.
Best Slashdot Co
well, everyone was pretty pushy about getting the 2.4 kernel out the door. Maybe linux suffered from the hype of the internet economy too?
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)
I didn't know the -ac trees had Promise IDE RAID support. I looked all over for a good solution for using that thing, after I carefully soldered on my resistor, only to find out that there was no good Linux support for the darned thing. Has anyone had any success using this thing in Linux (not using the closed-source drivers?) This is something I'd really like to see in a stable kernel.. does anybody know how to tell what -ac releases are stable, if any? **pounding head on cubicle wall** I suppose I can use software RAID if that's what it comes down to.
"Competing" ?
:)
Without these alternate kernel trees, nothing would ever get done. the -ac trees really aren't a tree I'd recommend for a production server unless it has a fix or driver that the server desperately needs... the -ac's are to test and impliment things in advance to KEEP the "stable" tree "stable", and keep Linus happy that the patches he's putting in the mainstream tree have been tested.
And no, I don't feel the 2.4 series deserves to be called stable, but I damn well use it anyway on my primary desktop box
Linus, GIVE US 2.5 TO PLAY WITH!
At regular intervals I take stuff from the -ac tree and feed it to Linus.
...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...
I also don't feed Linus code that has active maintainers unless the maintainer has asked me to do so.
So Linus eats code. Everything is so clear now...
I got my Linux laptop at System76.
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
Someone mod this parent up. Seems like a worthwhile patch.
there are no stupid questions, but there are a lot of inquisitive idiots
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.
Yes, indeed it is having problems.... My journal entry was made about 24 hours ago. It was gone this morning so we've had maybe over a day of problems now.
Give us an update, CT!
Oh, and ignore the 'game client' link below -- if it is still there. Yesterday it pointed to my journal entry.
Geeky modern art T-shirts
> "At regular intervals I take stuff from the -ac tree and feed it to Linus."
> Take that out of context and think about it.
Just because Alan Cox is east of the US doesn't mean he is a snake.
And why are all of you handing me my coat?
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
I thought that was a bug in a VIA chipset? I'm pretty sure the Athlon optimization stuff is pretty rock solid and definitely not experimental. I'd hate for them to start slapping the (EXPERIMENTAL) label on anything which might cause problems or conflicts on some specific platforms. (Although that's what MS did with their latest OS, didn't they...)
-- If no truths are spoken then no lies can hide --
Now I don't want to start a flame war here, but when someone says "Linux" what do they mean?
There are so many distributions, each with little kernel tweaks (RedHat IMHO is especially bad) and different userland applications. So, I have kernel 2.4.9 with what patches, and what userland apps, what compiler, etc.? I'm totally confused. What *is* Linux?
If I go to kernel.org and download a 30MB tarball of the kernel.... now what about the userland apps? Where do those come from? Who wrote "ps"? What version of "netstat" should I use? Which gcc compiler should I use?
However, with an OS like FreeBSD... "FreeBSD 4.3-RELEASE" refers to one and only one kernel & userland. No questions. No confusion. If there are problems with a particular version, I can retrieve a CVS snapshot of the kernel and userland sources at any point in time since the beginning of the project. Very impressive.
~g.
As a member of the GDB team (maintainer of the Linux/i386 port and co-maintainer of the threads support in GDB) I'm not aware of any coordination between the kernel folks an GDB at all. On top of that I'm not inclined to add support for this to GDB until it ends up in Linus' kernel. Anyway, the one-core-file-per-pid approach seems wrong to me. It's a waste of disk space since you're duplicating the VM for every pid. And isn't well suited to how GDB deals with multi-threaded core files on other platforms. A better approach would be to add an additional note with the register contents for each LWP to the same core file.
If anyone remembers, back when linux rolled to the spankin' version "1.0", Linus said, "Calm down children. It's just a number." The quote may not be 100% correct as this was many years ago, but the part about the version being "just a number" is as true today as it was then.
Linus and company may know how to write code, but it's very obvious they were never taught to manage all of their code. Talk about a black art. Linus' hatred of CVS doesn't make things any easier.
This is very interesting:l /0108.2/0416.html
http://www.uwsg.indiana.edu/hypermail/linux/kerne
It seems Alan Cox is considering his -ac kernel tree to be a legitimate alternative to the official "Linus" tree, rather than a playground for testing patches. He's actually perpetuating a difference between -ac and the official tree, in a way that breaks source compatibility between the two (albeit in a very small way.) The fact that RedHat's kernels are all based on -ac now bears this out.
Alan has forked the Linux kernel.
::meyhem::
I think he has Linus' blessing in this though. Reading between the lines, I think Alan has been taking on more and more work in the past year or so that had previously been Linus'. Linux is ten years old now; I suppose Linus is burning out.
And Alan works for RedHat too, which is one of the two distributions that I *know* will be around in ten more years -- they have a solid business plan. Alan is voracious, just tireless, and RedHat would hire the entire core kernel development team if they had to. Linux will not die for lack of a maintainer if Linus gets hit by a bus tomorrow.
"That's all I have to say about that" --Forrest Gump
Well, there's stable and then there's stable... 2.4 was, what, over a year past due for release? How many 1.3 kernel revisions were there before 2.0 was declared?
:-) It's time consuming work -- over 50% of work load at Make Systems was configuration management related stuff and there were only a few dozen people working on code.
:-)
A lot of things could be done differently. They, of course, won't because Linus hates CVS. Personally, I'd prefer something along the lines of ClearCase, but I'm paying for the licenses
Anyone who knows anything about code management knows what a "code freeze" is. They also know to begin working within new branches (long) before freezing previous branches. 2.5 should have been open for development when 2.3 was "frozen". And certainly parts of the current 2.4 tree don't belong there -- bug fixes and isolated back ports from the development branch are all that should be going into the 2.4 line. Additionally, it's hard to construct a schedule when you have no clear direction -- a list of features to be in X and which features are push further down the line.
Of course, I don't what the kernel versions to start looking like Cisco IOS tags
I really am very impressed with XFS; it seems like solid, proven code. I think XFS has the best chance at being the heavy-duty file system for Linux.
This is what I use with an external HPT366 to have it run stable:
/sbin/hdparm -c 3 -m 16 -u 0
cheers
I think, therefore thoughts exist. Ego is just an impression.
CVS has well earned it's hate. I'm all for version control, but CVS is an ugly hackish piece of crap. I sure wish Subversion would get completed (or at least releasable). As it is, CVS has too much momentum behind it because it "just works" (or "sorta" works). One of the curses of the Unix mentality (have separate tools which only do one specific thing), is tools that just *barely* do the job enough to scratch the particular developer's itch. Unfortunately version control is not that sexy.
It's 10 PM. Do you know if you're un-American?