I run an SMP and normal linux box, however anything that I don't compile
into the kernel I try to compile as a module.
Since I use INITRD and ROMFS for my boot image, it basically means
*everything* is a module. I have IDE and EXT2FS support in my initrd
image with a script to load them. kmod does the rest after the real root
is mounted. I use a script to update the initrd, so the whole thing is
automated.
What I don't have is an automated way of saying "Set all options to M if
possible". I would then only have to set ROMFS back to a static build.
It is actually a little worse. I can't always tell if "Manufacturer XYZ
support (Y/N)" means that I will then have a choice of drivers to compile,
or that this is a single driver that can be compiled as a module.
If the config was cleaned up it would be easier. I find lots of compile
bugs early. And missing symbols (I log depmod errors).
I do this for i386 but also have an alpha that I try to do similarly (all
modules).
Since PCMCIA works similarly (all modules), as much as people like
building static kernels, I think it would be more flexible to force more
things to only be modules. with INITRD they can be loaded by a second
phase of the boot (I think this works for everything except nfsroot). And
then we wouldn't need everything in the kernel tree, which I think would
be better. NTFS, HFS, and the Joystick driver were addons, and PCMCIA
always will be.
But with dozens of filesystems, and hundreds (or thousands?) of drivers I
think moving to something like this for 2.3 (initrd would be the standard
way of doing things, static drivers only if you really need them) might be
a better way to go. If I need ftape, I download it, unpack, and go to
/usr/src/ftape and do a make (and maybe a ./config just before). I could
symlink it and patch it into the kernel tree to make it static, but I
doubt anyone boots with ftape (I know, somewhere in the millions of users
are a half-dozen logging systems that do this...).
There would need to be some site for common drivers, but they could go
into a separate tree next to the core kernel source. Even now when
something changes in a filesystem, I often have to upgrade mount, and that
is not in the kernel tree. I also needed to change the ip configuration
tools, pppd, and various other things while 2.1 was being developed, and
none of them were in the kernel tree, merely URLs. So the kernel source
even now doesn't contain everything that needs updating. Treat drivers
and filesystems (and some network layers - I tried but failed to
modularize IPV4, though I came close) better than the programs like mount,
but lower than the things like task and memory management.
I know the decoupling will make some matters worse, but with modversions,
at least you know the drivers that *will* still work (but might get some
false negatives), but the kernel itself will recompile very quickly, so
you can then go into the (decoupled) drivers directories and see if they
work - and get an update or file a bug report.
This is already what happens with PCMCIA, so it already does work, and the
driver maintainers can decide if one or two code sets is appropriate for
even and odd kernels.
-
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/