[lkml]   [1997]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: initrd and NFS
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,

- "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 ?

- Werner

/ Werner Almesberger, DI-LRC,EPFL,CH /

 \ /
  Last update: 2005-03-22 13:39    [W:0.052 / U:2.268 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site