Messages in this thread | | | From | Werner Almesberger <> | Subject | Re: initrd and NFS | Date | Tue, 20 May 1997 08:14:31 +0200 (MET DST) |
| |
Jon Peatfield wrote: > If the change_root code were altered to take an already mounted > file-system, (rather than just a device number pushed by magic), then > NFSroot could be done by an initrd which mounts the filesystem (from > userland) and then signals the kernel to do the change.
This is a brilliant idea that takes the initrd design exactly to the point where it should go. We can also get rid of plenty of odd stuff in /proc/sys with that.
This may actually be the right time to digest the experience people had so far with initrd. I think the basic concept is fine, but there might be room for improvements in the "care and feeding" section, namely:
- "on the fly" updates: not mainly an initrd issue, but if the underlying file system is able to grow, hard disk-based initrds would become easier to maintain. (The general goal is to keep initrd as small as possible.) - shared libraries: I think it would be great if we had some means to generate a customized libc without recompiling, e.g. scan all the executables for symbols, then copy the relevant modules from the system's libc to a new, smaller libc. Right now, it's either static linking or a lot of guesswork (and hours of libc recompilation). Does this sound feasible ?
Are there any other problems initrd users have experienced ?
Thanks, - Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_133__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
| |