Messages in this thread | | | Date | Mon, 14 Jun 1999 02:59:03 -0700 | From | "H. Peter Anvin" <> | Subject | Re: 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 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/
| |