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 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.
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 ...
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.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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/