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
changes.
> > 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
painful.
> 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.
-hpa
-- "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 http://www.zks.net/p3/how.asp- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/