> Your point is understandable. However, a lot of the kernel code isn't used
> in a simple installation. Look at the Ethernet card drivers, how many
> of us have 5 different cards in a machine? Its the driver code have seems
> to be expanding by leaps. Perhaps just having "drop-in" source modules for
> netdrivers and SCSI drivers. These take 4.5 megs combined.
Then cut them out somewhere before you transfer your kernel home. You decide
what you cut, and it's your fault then, that you can't use patches anymore.
>
> The idea isn't to make it hard for developers, but the size of the kernel
> is a consideration that should be addressed. I've not seen much of
> this thread but I agree something needs to be done fairly soon. The
> question is: how?
But splitting the source as you propose makes the maintenance a nightmare.
Consider users with 1.3.x kernel using SCSI drivers from 1.3.y and net
drivers from 1.3.z, ...
In some cases this work, but you should rather know what you are doing. And
how do you solve the ``splitted-patch'' problem? (see my over mail.)
If you want to save bandwidth, because you are running
on the bleeding age, then use patches, else it shouldn't matter that much
if you upgrade say every six monthes or even more seldom.
The point is, that splitting the kernel sources makes for probably more
work of our Linus, and I'd rather see him spent more time on processing
patches then packaging up the sources. (I know, especially the
linux-a.b.c-part.tar.gz part would be rather easy to package. But patches
don't integrate into your model very well.)
Andreas
-- Andreas Kostyrka Email: andreas@medman.ag.or.at Fax: +43/1/7070750 Tel: +43/1/7077571, +43/664/3020166 (cellular) Copyright 1996 Andreas Kostyrka. Microsoft Network is prohibited from redistributing this work in any form, in whole or in part.