On 9/14/05, Jason Thorpe <thorpej@shagadelic.org> wrote:
>=20
> I don't see anything wrong with keeping MNT_UPDATE as-is.  Its
> semantics are "update the mount", i.e. change from r/w to r/o or
> whatever.  MNT_GETARGS ... well, I have other opinions on that, as
> well... I would rather we had string-based mount arguments, rather
> than the binary blobs we have now.

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.)

Basically, I see three operations over a mount point, all of which
should be handled independently:
1) Mount it, using mount(2).
2) Change any of its properties, through the new fsctl(2) or whatever.
3) Unmount it, using unmount(2).

> > Do you think this is correct and flexible enough for the current and
> > future purposes?
>=20
> I think I would like to have an fsctl(2), sure.

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?

> But going back to
> the original discussion about NFS exports, I think that we should
> switch to a model where the export list is not maintained by the
> kernel, but rather ONLY by mountd(8).  I believe someone else
> mentioned this as what is done by Solaris...
>=20
> In this model, the kernel would make an upcall to mountd(8), which
> would either approve or deny, and the kernel would cache the result.
> Updating the export list then becomes a matter of simply flushing the
> kernel's "export cache".

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?

Thanks,

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