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

    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:0.019 / U:31.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site