Jim Cromie wrote:
24-ac
major product of this tree was VM that went into 2.4.10
oops. I meant -aa there.
iirc, there was some hullabaloo about how that VM got in,
directly by Linus, w/o the usual review.
That was true for both of the 2.4 VMs, actually :)
I was in Europe for 2 weeks for conferences, and during a
brief opportunity to check my email I found an email from
Linus asking why I hadn't fixed a bug yet in the VM that
he merged almost a week ago - without me knowing that he
merged it, because I was offline...
While we're talking 'dirty laundry', what was the day-Zero defect
in 2.4.11 that caused it to be marked -dontuse in the archive ?
http://www.kernel.org/pub/linux/kernel/v2.4/
IIRC that was some inode related thing in the VFS, not
something in the VM.
The 2.4 VM saga really hammered home the lesson that changes
to the upstream kernel need to happen in small, incremental
bits and not by a wholesale change of source code.
As a patch grows larger, the probability that it includes
serious and hard to fix bugs gets larger and larger.
Small patches not only have a smaller chance of containing
such bugs, but they are also much more easily identified as
the source of a problem, thanks to tools like "git bisect".
Ironically, the 2.4-ac tree stabilized the VM that was removed
in 2.4.10...
One of the things that happened here is that Alan and I
spent a lot of time fixing stability issues in the early
2.4 VM, getting things stable around 2.6.9-ac and pretty
well performing by 2.6.12-ac.
Meanwhile, it turned out that Linus was upset mostly
about the performance issues seen in the mainline kernel,
and not nearly as much about the stability issues.
That was quite a surprise for me at the time...
Of course, back then the kernel still worked with the
manual applying of patches and "regular" publishing of
large patches. This means that people spent a lot of
time hand-merging patches, had less time to work on
and discuss code and binary search like "git bisect"
was impossible.
Good distributed revision control is what made merging
small changesets a possibility, and is probably responsible
for quite a bit of the quality improvements the Linux
kernel has seen over the last few years.
The two-stage merging model (staged by Andrew and shaken
out before being sent to Linus) is another big process
improvement, allowing us to introduce new kernel changes
quickly. This is pretty much a requirement with the
Linux userbase being as large and diverse as it is today.
24-rmap
reverse mapping was merged into 2.4.??
Nope, it got merged into 2.5.
Thanks for the clarification, ideas.
--
What is important? What you want to be true, or what is true?
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
