[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: initrd redesign (was Re: Partition nightmare Was: Migrating to larger numbers)
    Werner Almesberger wrote:
    > H. Peter Anvin wrote:
    > > Actually you can; it's called initrd. Currently, of course, initrd
    > > uses this funny hybrid user space-kernel space scheme for remounting
    > > the root;
    > Originally, the idea was to keep this part as simple as possible a) for
    > scripts (everything can be done with echo - no need to have a mount
    > program or such), and b) to keep the kernel changes small. Since initrd
    > environments tend to get pretty specialized anyway, point a) is probably
    > obsolete. b) is always negotiable :-)

    I don't think (a) is an issue; /bin/mount is not a big program. I don't
    think that my (admittedly limited) version would require that many

    > > I believe that should be changed so that you actually mount
    > > the new root in a standard fashion and pass the kernel a file
    > > descriptor to the new root.
    > I'd actually favour an approach that completely de-specializes things,
    > e.g. by adding a mechanism to allow mounted file system to be moved to
    > other places, including on top of the existing root. Then make it
    > possible to move a file system with another one on top to a different
    > place, or to unmount it. I think there are actually some patches for
    > at least part of such functionality floating around.

    That would be nice, but may complicate things unneccesarily. In the
    general case, you may have to worry about garbage-collecting parts of
    the filesystem that are now unreachable, and that would be majorly

    > This would also remove the need for a special directory on which
    > initrd gets mounted if it is busy during the transition (i.e. /initrd).
    > The remaining problem are things like NFS root, which do some "magic"
    > when mounting the root FS. (Are there others ? UMSDOS ?) I'm not sure
    > what to do about this - conceptually, NFS root should of course be put
    > into user space, but then it's so damn handy to have it in the
    > kernel ...

    I actually think that an nfsroot.gz initrd would do everything the
    current kernel mechanism does.

    > In any case, there has to be a transition period with both mechanisms
    > available, so one could use this time also to explore what solutions
    > work best for NFS root.
    > The next step would then be to let init exit to another init. I'm not
    > sure if "exec" covers all cases, so I'd be more inclined to do all
    > this in an exec-init loop, with the possibility to change the name of
    > init (a la init=... from the boot command line) via /proc.

    exec() init works just fine. I have used it. I don't think there is
    any need to put that in kernel space.


    "The user's computer downloads the ActiveX code and simulates a 'Blue
    Screen' crash, a generally benign event most users are familiar with
    and that would not necessarily arouse suspicions."
    -- Security exploit description on

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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