> >>>> My point is this: Why is Linux kernel source distributed as
> >>>> one big lump? Many of the drivers could be distributed seperatly
> >>>> as modules, such as file system drivers, some Networking protocols,
> >>>> Net cards etc... and have different people maintaining them. Ftape
> >>>> already does this, and it works. (Although he is mumbling about
> >>>> integrating it with the kernel...)
> >>
> >> One _major_ advantage as having it all in one lump is that when I change
> >> some interface, I can then fix all the pieces that use that interface,
> >> rather than just tell people who maintain all the pieces to fix it.
> >> Believe me, it makes things a _lot_ easier.
> >
> > 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.
> >
> > 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?
>
> Put the source tree on a FTP site untarred, and write a tool to get
> only what is needed. Change patch/diff to know the difference
> between a missing file that needs to be added and a missing file
> that is only missing because it was not downloaded. This should
> work for most kernel patches. Also, hack the Makefiles to ignore
> missing directories.
>
> I think it would be easiest to do this by directory only.
> Example: if you have include/i386, you must have all of it.
Or write a script to remove all .c and .h files without matching .o files.