lkml.org 
[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.084 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site