On 9/14/05, Jason Thorpe <thorpej@shagadelic.org> wrote:
>=20
> On Sep 14, 2005, at 3:49 AM, Julio M. Merino Vidal wrote:
>=20
> > But these are all different than mounting a file system, thus IMHO,
> > mount(2) is the wrong place to handle them.  I really find the current
> > approach of flags to change behavior weird.  (Specially having to
> > execute completely different operations inside the vfs_mount hook,
> > where one could use independent and smaller hooks.)
>=20
> I'm ambivalent on the MNT_UPDATE thing, really.  MNT_UPDATE does have
> "replace all previous mount options with these new ones" semantics,
> so it seems sort of "natural" to leave it where it is... but I don't
> really have a strong feeling either way.
>=20
> > I'm interested in what you think about adding these features in
> > fcntl(2).  (Note that the current implementation of fcntl(2) seems to
> > have been designed leaving room for file system specific operations,
> > which is what we want.)  Any comments?
>=20
> I don't think it should be in fcntl(2).  fcntl(2) operates on
> individual files / directories.  fsctl(2) operates on the file system
> instance.

But we already have functionality in fcntl that does not operate on
individual files/directories (F_CLOSEM, F_MAXFD or all the LCFN*
commands in lfs).  I'm not saying this is right -- and IMVHO, it's
not -- but it's already there.

Also... I think I've just found an "advantage" of using fcntl; dunno if
it's really a good thing or not (or even if it's useful).  This one is:
you'd lock the file from userland to later do a set of fs specific
operations without interferences.

> > That indeed sounds nice... but it's a bigger project than what I
> > intended
> > at first (clean up existing stuff).  Maybe we can leave this for a
> > later
> > step?
>=20
> Why change it twice?  It seems like it's actually less work to do the
> heavy-lifting-in-mountd scheme, because it doesn't require you to
> implement fsctl(2).

The thing is that I have no idea about how to do this at the moment.
Do we have any example in the kernel on how to cummunicate it
with an userland process so that the latter has to return a value to
the former?  Maybe the userfs SoC project has a decent way to
do this?  What happens if the kernel requests a mount export entry
to mountd and mountd crashes/locks?

And even in this case, wouldn't we still need fsctl(2) to tell the kernel
to clear its export list cache you mentioned?

Thanks,

--=20
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/