Re: 2.4.0-test6 ppp trouble
Adrian Cox wrote:
> Adam C Powell IV wrote:
> > Having five people maintaining five PPC trees and occasionally sending patches to
> > Linus seems the wrong way to maintain an architecture, and an implicit
> > resignation to the total worthlessness of any PPC material in the stock tree at
> > all!
> One problem is keeping up with PowerPC hardware. It's all different.
> Most bootroms don't leave enough information, so the kernel is full of
> code which guess which variety of motherboard it's running on, then
> behaves accordingly. There's all the different Apple chipsets, all the
> embedded boards, a different interrupt routing for each prep machine.
> There just aren't as many types of Alpha, and there isn't a new 68k
> machine every week. A lot of differences in the five trees are about
> coping with this.
It seems your alpha info is about as well-informed as my m68k info. :-)
Have you seen how many different alpha kernels are in slink? IIRC it was about 15,
one for each subarch, and several new subarches have since come out with no slink
support at all! (E.g. just about all of the 264 machines, from nautilus to tsunami to
DS10/20 to ES40.) Today all but a couple of them are supported in the "generic"
kernel subarch (this wasn't easy to do, and isn't easy to maintain)- which is kept
current in the stock tree.
This way, everybody has the same features, the same place to get kernel source as the
rest of the Linux world, the same reference point for debugging, and mostly the same
bugs (e.g. etherexpress cards are currently broken for all alphas in 2.4.0-test*, and
tsunami subarch irqs are currently broken in 2.2.17pre*).
Of course, individual devs will have their own trees on their own hard drives, but the
discussions about what breaks when why, and all of the patches sent to mailing lists,
refer back to the stock tree. So instead of talking about "Jay Estabrook's tree", we
talk about "Jay Estabrook's patch against 2.4.0-test5".
The opposite approach of maintaining separate trees seems to be what Linus really
hates about ISDN development (though they seem to be getting better), and also what's
behind the "cathedral" criticism of the old net driver development style. With
separate trees, one can never be certain of whether we really have 2.4-style softnet
behavior and memory management, or perhaps this person's particular tree has
networking from 2.3.2x and memory management from 2.3.3x because more recent versions
broke stuff and a merge was put off until there's time to fix it. (Not saying this is
the case, but nothing is guaranteed.)
So again, I think the Alpha way of working as closely as possible with the stock tree
is more intelligent, and leads to faster development of a stable kernel with all of
the features in the stock tree, but apparently I'm outnumbered here. :-)
On the "curse of the gifted", this was on L-K, I saw it in the LWN kernel section.
Eric Raymond was saying that to date, Linux has progressed without using standard
software engineering tools like regression testing and tinderbox build servers and
debuggers because Linus is just so good that he could manage it all in his head. Like
a gifted high school student who aces tests without studying, but is slowly
overwhelmed by the increased demands of college; Linux is growing beyond the Linus'
ability to keep it all in his head, and will need some of these more advanced tools to
deal with the ever-increasing demands which are being placed on it.
Welcome to the best software in the world today café!