On Sunday 23 December 2001 1:02 am, Dave Cinege wrote:
> On Wednesday 19 December 2001 4:34, James A Sutherland wrote:
> > Initramfs will do this, it seems. Alternatively, you might have to copy
> > some files into a tarball - oh, the stress! Oh, wait - you just compiled
> > 100+Mb of C source to make that kernel and the modules. Somehow, making a
> > tarball out of the modules doesn't seem too stressful to me.
>
> Do it for 15 production systems, each with varying hardware.
> Now do it again for kernel revision 2. Now again for rev 3. Now
> again for rev 1 of 2.4.17...
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.
> OR
>
> 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
setups.)
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:29 EST