Re: Why not make Linux source modular?

Dan Miner (dminer@nyx.net)
Wed, 28 Feb 1996 21:59:25 -0700 (MST)


According to Andreas Kostyrka:
>
> > 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, ...

Very good point. It will only a take a couple of "Opps"es to teach
a user. And it'll land in the FAQ. A simple ftp command of
mget linux*{common,net-generic}*1.3.2000.tar.gz

isn't too much trouble.. I use it alot for my favorite patches. :)

> 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.)

I thought about this one. It's a tough one. But with "drop-in" source
modules, you would simply add the *required* parts and apply the
patch. Then Linus or whoever could 'make src-modules'

> 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.

Actually, I use patches a great deal. I have nothing against them. :)
It's the ever growing size of the main distribution due to driver
expansion is my problem. [Don't read that I do not want them.. :)]

> 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.)

I didn't mean for that example to be the ruler for doing it. It was
an example. A more reasonably partitioning would be *something* like
this:

linux-<ver>-main.tar.gz
linux-<ver>-cdroms.tar.gz
linux-<ver>-scsi.tar.gz
linux-<ver>-net-generic.tar.gz
linux-<ver>-net-drivers.tar.gz
etc.

Again, this is only an example. :)

Anyway, there is some serious issues I think this brought to the
front that people don't seem to mind. The biggest one I find is
the naughty dependencies of global resources to specific drivers.
[example: linux/blk.h and drivers/block/ll_rw_blk.c]

I think splitting the sources would force some type of correction
to this. I don't want to create headaches with this. Perhaps
people just thinking beyond "It's too much trouble" and seeing
what reasons in the kernel exist to prevent something like this
from ocurring will make this whole discussion worthwhile. Nothing
hurt by talking about it and going thru the motions to find the
walls in the way. :)

Regards,
Dan

-- 
Dan Miner					dminer@nyx.cs.du.edu
	"The longer I stare at this screen; the blanker it gets."
						Linux: try it, you'll like.
"Your program is encoded in pi."		I started with a 64