> As you all may have noticed, the kernel is growing enormously in size,
> and the latest kernel is approx. 9 meg. compressed, and almost 40 meg.
> uncompressed. Wouldn't it be better to somewhat modularize the kernel?
> I have two suggestions:
> First, the kernel could be micro-kernelized, Having in the kernel the kernel
> (kernel/, arch/*/kernel), the memory subsystem (mm/, arch/*/mm), the vfs
> (fs/) and the ext2fs (or whatever root fs one may have), and the important
> device drivers (like drivers/scsi, drivers/char/console.c etc ...). The rest
> of the drivers could be separate modules, which can be downloaded seperately.
> Second, you could modularize the kernel on source-level. Currently, you
> _must_ download the whole tree, even if you don't have scsi, sound, cdrom,
> isdn, networks, and you have to download 6 archicture trees, when you only
> need one (ok, some people two or more). If you download a tree, unpack it
> and remove, say, the net/ subsystem, the kernel won't compile.
> It would be (or: Would it be) handier to make different trees, like:
> - kernel.tgz (with kernel/, mm/, fs/, and all important drivers);
> - arch_i386.tgz (and also a arch_alpha.tgz, arch_sparc.tgz etc.);
> - scsi.tgz;
> - cdrom_drv.tgz;
> - isdn.tgz;
> etc...
Both of these options do the same to the amount of different files you need
to locate, identify and download... I think splitting the kernel up is not a
bad idea, but it _needs_ to stay simple. Yesterday I looked at egcs, which
has various files containing various frontends and utilities, testsuites
etc. I couldn't easily see which ones I needed, so I just downloaded the
whole bunch -- I'm exceptionally lazy and have the bandwith to afford it ;)
(it works fine, by the way, running a linux and libc6 compiled with
egcs+pgcc now)
Simply splitting the kernel up into different, but complete trees for each
architecture sounds like a much better idea. The files would still be rather
large, of course, but thats the price you pay for user-friendliness. You
shouldn't forget a lot of the people who compile a kernel don't really know
what they have, they just know what to change in 'make xconfig'. Which is
why the default config shouldn't change too much, or include 'dangerous'
settings.
Splitting the kernel into different achitectures isn't that simple either,
by the way, as you have to be absolutely 100% sure you aren't missing files.
Splitting the kernel is definately something for the development kernels,
and should not be introduced into the 2.0 kernels. I don't know if the need
for split kernels is high in the development series, though, so it might
even be delayed for the 2.2 kernels ?
Regards,
Thomas.