> I would suggest splitting the kernel source into that which might be
> required to boot and that which is not required to boot and is easily
> handled as a module.
How about devices required to boot but easily handled as a module ? Like module
for handling my AIC-7890 ? "Required to boot" and "easily handled as a module"
are not opposited !
NPU emulation -- required to boot and not easily handled as module
AIC-7890 -- required to boot but easily handled as module
procfs -- not required to boot but not easily handled as module
sb16 -- not required to boot and easily handled as module
All four variants are there in kernel just now :-)
> I.e. almost all block device drivers stay with the main kernel tar ball.
What for ?
> Almost all character devices and all network drivers could easily get moved
> into a Linux Modules source tar ball that could have an independant (to the
> kernel) life.
"Easily" ? Are you joking ? With moves like planned move of rename() from
filesystem-level to VFS-level are forced to redesign all modules (AFS peoples
are heppy to hear about this move, I know :-))) ! So if module will be
saparated from main kernel this will become mantainance nightmare (like PCMCIA
just now).
> Is there any compelling reason for being able to compile ethernet drivers
> into the main kernel? They work fine as modules. Ditto for serial, isdn,
> sound, etc.
Some peoples just hate modules and it's just easily to mantain consistency
with current big tarball then with proposed scheme...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/