> 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.
Yes. Unable to deal with the global root, but it's not hard to add. The
right solution being to add the full-fledged namespaces, though. Doable,
but will require some NFS cleanup beforehand.
> 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.
Oh, *that* is mostly done. I've written re-exec stuff about a year ago
(heck, year and half) and it's in sysvinit since 2.74. telinit u and there
you go. It may require a bit of cleanup - I can't tell right now how well
it will work on the early stages, but fixing it should be easy. It creates
a pipe, writes signature there, forks, child marshalls the state through
the pipe, parent does exec(), main() sees the pipe open (IIRC on
descriptor 11), reads the signature and decides that it should read the
state. Then it parses the state (passed in text form) and resumes the
normal work. Child exits when it had fed everything to the pipe. It is
used for libc and init upgrades without rebooting (at least by Debian).
Remaining cleanup shouldn't be hard - most likely it would be the matter
of passing several additional items.
-
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/