i.e. build kernel image and associated modules (you need to do that anyway).
Then have a configuration file on each machine which drops the modules you
need into a tarball.
Or have a configuration file which does precisely the same thing at boottime,
with extra overhead in the boot loader.
> List the names of the modules for boot ONCE in the systems 'grub.conf'
> file, and just create a 'current' symlink each time you install
> a new kernel and modules. A simple user land util can parge depmod to
> give you to right order...no bloat needed.
Which you could also do with a standard shellscript in your initfs, thus
avoiding any extra bootloader complexity at all.
> FYI I only ned create a 'vmlinuz' for new kernel install as it is.
> If I could do the same for modules, I wouldn't have a 1.3MB
> 'catch all' bzImage.
Eh? WTF does bzImage have to do with this? You can also standardise your set
of modules: just build all the ones you need.
> > OK, make the conf file a shell script which copies the modules into a
> > tarball or initrd image.
> Oh that's nice, clean, and standardized! Again do it for 15 machines...
Remembering that in most cases loading drivers for hardware you don't have is
harmless, I doubt the 15 all REQUIRE different sets of modules. You could
probably get away with attempting to load a single set; the unneeded drivers
will just fail to load.
> Many of you people spouting about 'kernel design' really need to get
> a clue about putting these things into real world practise, across
> mutiple machines, that must stay running...
If nonstop uptime is a requirement, you can't change kernel anyway, so what's
the problem? :-)
(And here, at least, most of the hardware is deliberately homogenous: of the
couple of thousand PCs in use, there are only half a dozen distinct hardware
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/