Messages in this thread | | | Date | Mon, 14 Jun 1999 13:22:45 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: initrd redesign (was Re: Partition nightmare Was: Migrating to larger numbers) |
| |
On Mon, 14 Jun 1999, Werner Almesberger wrote:
> 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/
| |