What Happens To -AC (And Other) Kernel Mods?

RedLeg wrote with this poser: "So, looking at the changelog for the 2.4.9 kernel release, I see a few '- Alan Cox: driver merges' entries. Intelligent consumers of (or those of us who modify them for our own uses) RedHat Kernel src.RPMs look at the patches in the RH kernel builds. Alan's (and other persistent RH) patches don't seem to be integrated into Linus' 'mainstream' kernel trees on any kind of a predictable basis, and this frequently causes projects like freeswan to have difficulty merging their patches (not intended for kernel inclusion) with kernels that appear 'in the wild' like the kernel RPMs from RedHat. Often, kernel patches for obviously older kernel versions continue to be applied (in the RPMs) to newer kernel versions. Alan is a RedHat-er, so he obviously has an inside track to RedHat kernel builds, but he's also Linus' Right-Hand man, but his patches are not (apparently) consistently making it into the 'mainstream' kernel. What am I missing?" Who better to answer this question than Alan Cox? Alan was kind enough to write an explanation of the (still complicated) process of merging -- and it's not as simple as who works for what distro maker ;)

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.

Comments

OH YEAH BABY - FP!

[Anonymous Coward]

I got the first post LONG BEFORE YOU OTHER MORONS DID! HAHAHAH! Only I know the secret.

Peace Out.

Brought to you by SOBMAN

Re:OH YEAH BABY - FP!

[Anonymous Coward]

Don't be so retarded. Props to CT!

Random Crap

[londenberg]

Testing what happens when I post random crap.

Re:Little brown ring, little brown ring

[Anonymous Coward]

well, say what u will, at least it's original hehe

Ask Slashdot

[zpengo]

WTF is going on with the front page?

Re: The Truth About CmdrTaco, VA, and Microsoft

[Anonymous Coward]

What a fucking riot!

On the other hand, what else would you expect from a bunch of computer geeks like Taco and Microsoft trying to pull cloak and dagger shit?

If this is true, I'd like to see coverage by major news organizations; not that Slashdot is or ever has been newsworthy, but the Microsoft angle certainly is (the shareholders should be worried, anyway).

If you made all that up, you are one talented sonofabitch. Ever think about writing for the X-Files?

Re:Post-Mortem debugging of multithreaded processe

[Anonymous Coward]

hhahahhaha, too funny.

Linux is dying. Movie at Eleven.

[Anonymous Coward]

Taco's buying an XBox. He doesn't want anything to do with you lot now that he has entered puberty.

above script is broken

[Anonymous Coward]

I tried the above script and it didn't work properly out of the box. I made the neccessary changes here.

#!/bin/bash

shopt -s -q dotglob
function cox_patch() {
for test in $1/*
do
if [ $test = '.' -o $test = '..' ]
then
break
elif [ -d $test ]
then
cox_patch $test
else
ac_update $test
fi
done
}

function ac_update()
{
TMPFILE=`mktemp /tmp/patch.XXXXXX` || exit 1
sed -e 's/\([Aa]\)\(l\)\(a\)\(n\)\(\ *\"*[[:alnum:]\ ]*\"*\ *\)\([Cc]\)\o\x/\1\na\l\5\6\o\ck\s/g' $1 > $TMPFIL
E
mv -f $TMPFILE $1
}

cox_patch .

WARNING !!!

[Anonymous Coward]

Script spawns 100 netscapes with goatse !!!

Re:(OT)Slashdot does not censor.

[Rick the Red]

Then where's the Parent to this comment (#2204931)? What's its number, so we can all read it? If you check the "Parent" link in that comment, you'll see it points to comment zero (0). Either the parent has been deleted, or the "Parent" link has been altered. Now, who can make changes like that around here...? Can you? I sure can't!