Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 May 2002 14:44:47 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        Maxime Henrion <mux@freebsd.org>, arch@freebsd.org
Subject:   Re: a virtual fs to allow root mounting of any fs without special code
Message-ID:  <3CEABFCF.35B80817@mindspring.com>
References:  <Pine.NEB.3.96L.1020521172613.79313X-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Robert Watson wrote:
> > You need to do exactly what you said you don't want people doing, in
> > order to achieve proper jails that are indistinguishable by way of the
> > root mounts.
> 
> What I'm saying is that if it's a limited-purpose file system that doesn't
> follow the normal conventions for vnodes and their relationship to a
> struct mount, we need to prevent people from mis-using the file system, as
> it will violate existing code assumptions about the presence of a struct
> mount under certain circumstances.  If we would like people to be able to
> mount it just about anywhere following boot (as with any other synthetic
> file system), we'll need a heavy-weight struct mount, which rootfs
> currently doesn't have.

I think if it's integrated, it needs a "struct mount".

Personally, I'd like to see the "real" root union mounted over it.


> That said, I'm not sure what you're saying applies.  There's nothing
> special about "rootfs" itself, it's pretty minimalist, what's special
> about it is that it gives you a place to stick devfs during the bootstrap
> (etc) so that you can get rid of special mountroot mounting procedures for
> other file systems.  I.e., the magic in Maxime's patch is in the
> general-purpose root mounting case in the boot code, not in rootfs itself.

I was really torn on this patch, so I didn't say anything
previously: it implements part of one of my suggestions, but
it tends to encourage people to not implement the correct
solution to root vs. non-root mounting, since it offers a
workable workaround to doing the right thing (seperating the
mount-into-mountlist from the mount-into-fs-hierarchy is the
cannonically correct approach).

Now that you've implied the very thing I feared, I guess I
need to say something.

I would be really unhappy if the mount during boot ended up
being significantly different than the mounting after boot.
8-(.

There really needs to be a new VFSOP "MOUNTEDON", used to set
the "last mounted on" information, which is the main difference
(from an FS perspective) between root and non-root mounts.  The
vnode overlay is also a difference, but it's really obvious how
this could be handed in an FS independent manner in higher level
FS independent code (this is where the mount-into-fs-hierarchy
should be done).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CEABFCF.35B80817>