--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=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.
>=20
> 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.
>=20
> Given these comments, I've started the implementation of a fsctl(2)
> function call, with the following signature:
>=20
>     int fsctl(const char *path, enum fsctl_command command, void *data);
>=20
> 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?)

Use and integer and steal the implementation from ioctl() and fcntl(). Or=
=20
we could decide to implement all of this as fcntl()s on a file in the file=
=20
system (which is what HPUX does AFAICT, though they have a special fsctl()=
=20
call).

Actualy, why _can't_ we just use fcntl() to do it? Then we don't have to=20
add a new system call.

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

I don't think we want to change multiple mount points at once. I think=20
what we really want to do is change multiple exports on one mount point at=
=20
once. Thus we want multiple data payloads to one destination, not multiple=
=20
destinations.

> 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):
>=20
>     int fsctl(enum fsctl_command command, struct fsctl_data *data,
>         size_t ndata);
>=20
> where 'data' is a map between paths and structures, as in:
>=20
> struct fsctl_data {
>     const char fd_path[MAXPATHLEN];
>     void *fd_data;
> };
>=20
> 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.

I think our lives will be much simpler if we don't do this. If we try to=20
change multiple mount points at once, we could get into all sorts of=20
update and locking issues. I think one mount point per call will work=20
quite well and will be very solid.

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

Sounds good.

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

As above, I like the idea but I want to change only one mount point at=20
once.

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDJbWXWz+3JHUci9cRArkUAJ9d8zCthL3GbFwt+IrtOkuaZv5H2wCgijbL
5BAox/zyp2pHnNYukfucnNo=
=4BcJ
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--