On 9/11/05, Frank van der Linden <fvdl@netbsd.org> wrote:
> Julio M. Merino Vidal wrote:
>=20
> >Hi everybody,
> >
> >while adding NFS support to tmpfs, I found that the current way to
> >change NFS export information is... how could I say it... very ugly.
> >It seems to be a bandaid over what was used in the past to mount
> >FFS systems, which makes it confusing and difficult to extend.
> >(Don't we aim for clean design? ;-)
> >
> >
> Hi Julio,
>=20
> I agree with most of these changes, but I'd like to see an additional
> change: overloading the mount system call with export functionality is
> 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?)

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.

In order to allow this, I think the following could make more sense
(none of the stuff below is implemented, so it may contain errors):

    int fsctl(enum fsctl_command command, struct fsctl_data *data,
        size_t ndata);

where 'data' is a map between paths and structures, as in:

struct fsctl_data {
    const char fd_path[MAXPATHLEN];
    void *fd_data;
};

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.

In the (near) future, we could migrate MNT_GETARGS and MNT_UPDATE
to this new system call, as well as other stuff like the quota
management.

Do you think this is correct and flexible enough for the current and
future purposes?

Thanks,

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