On 9/12/05, Bill Studenmund <wrstuden@netbsd.org> wrote:
> On Mon, Sep 12, 2005 at 11:05:21AM +0200, Julio M. Merino Vidal wrote:
> > On 9/11/05, Frank van der Linden <fvdl@netbsd.org> wrote:
> > >
> > > I agree with most of these changes, but I'd like to see an additional
> > > change: overloading the mount system call with export functionality i=
s
> > > just wrong. There should be a seperate exportfs system call.
> >
> > We all agree in that a new system call is needed.  Some also want this
> > new interface to not only manage NFS exports but also to allow changing
> > other settings from a mount point.  I think this is a good idea too.
> >
> > Given these comments, I've started the implementation of a fsctl(2)
> > function call, with the following signature:
> >
> >     int fsctl(const char *path, enum fsctl_command command, void *data)=
;
> >
> > At the moment, command can be one of FSCTL_EXPORT_NFS_GET or
> > FSCTL_EXPORT_NFS_SET, to query or set NFS export lists respectively
> > based on the given path.  (Minor question: can an enum be used as a
> > system call argument, or should I better use an integer?  If not, why?)
>=20
> Use and integer and steal the implementation from ioctl() and fcntl(). Or

OK, but is it anything wrong in using an enum? (Such as the type to
represent it may change or something like that?)

> we could decide to implement all of this as fcntl()s on a file in the fil=
e
> system (which is what HPUX does AFAICT, though they have a special fsctl(=
)
> call).
>=20
> Actualy, why _can't_ we just use fcntl() to do it? Then we don't have to
> add a new system call.

I think we can, but IMHO, it looks wired.  Why do I have to open a file
when what I really want to do is get or set the properties of a mount
point?  I think that passing a path and letting the kernel do what it needs
looks better (as in statvfs(2)).  (We'd later discuss if the call should
enforce the path to refer exactly to a mount point or any file within it.)

Also, if we used fcntl, we'd have two "authentication" levels in the
trace.  First, open the file using the corresponding permissions, flags,
etc.  Then, do the fcntl, which will fail in most cases if the user is not
root.

> > The problem with this interface is that it doesn't let you change
> > multiple mount points atomically, as some others have suggested.
> > I also agree that having this feature could be nice.
>=20
> I don't think we want to change multiple mount points at once. I think
> what we really want to do is change multiple exports on one mount point a=
t
> once. Thus we want multiple data payloads to one destination, not multipl=
e
> destinations.

Ah, OK!  I misunderstood the initial suggestion.  Although it seemed
nice to me at first, I can't think of a good reason about why it could be
useful (I mean, the ability to change multiple paths at once).

> > Given this interface, each 'command' can provide its own structure
> > for the fd_data parameter.  E.g., the FSCTL_EXPORT_NFS_{GET,SET}
> > calls could return or receive, respectively, a struct export_args.
> > Also, each command can operate on multiple mount points atomically.
>=20
> I think our lives will be much simpler if we don't do this. If we try to
> change multiple mount points at once, we could get into all sorts of
> update and locking issues. I think one mount point per call will work
> quite well and will be very solid.

True.  I was trying to work around the locking issues by sorting the
mount points, avoiding duplicates and locking them in order (which I think
should work).  But this won't be needed at all.

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