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

On Mon, Sep 12, 2005 at 09:20:13PM +0200, Julio M. Merino Vidal wrote:
> 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:
> > >
> > > 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 *dat=
a);
> > >
> > > 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
>=20
> OK, but is it anything wrong in using an enum? (Such as the type to
> represent it may change or something like that?)

Yes. I think the problem with an enum is that you have to expose the enum
to all places where you use the prototype, and once exposed, I don't think=
=20
you can change the enum. The compiler has to know how big the enum is, so=
=20
it has to know all the elements to know the largest. Thus it turns into a=
=20
mess.

With an int, we hide all the details.

> > we could decide to implement all of this as fcntl()s on a file in the f=
ile
> > system (which is what HPUX does AFAICT, though they have a special fsct=
l()
> > call).
> >=20
> > Actualy, why _can't_ we just use fcntl() to do it? Then we don't have to
> > add a new system call.
>=20
> 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 nee=
ds
> 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.)

I can think of two reasons. The first is we already have ioctl and fcntl,=
=20
both of which have the ability to handle arbitrary operations. We're now=20
proposing a third. Do we really need a third such call?

Second, will we be doing one operation, as in statvfs() where we get info,=
=20
or will we be doing a sequence of operations? If it's the latter, the=20
fcntl() approach is a little easier as we only do path resolution once.

Granted, I don't think we will be doing any fs operations which need to=20
happen in the fast-path, so it doesn't make a TON of difference, but it=20
can be a bit easier to just do the lookup once.

HP-UX's fsctl(2) call uses a file descriptor, so we have prior art here.

I'm not saying we MUST do this, I just want us to explore it.

It could be we want length and command separate, so we do want something=20
other than fcntl().

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

So?

> > > 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=
 at
> > once. Thus we want multiple data payloads to one destination, not multi=
ple
> > destinations.
>=20
> 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).

I can think of places where it would be "useful," but as someone who
programs both userland and kernel, none of them are worth the effort the=20
kernel would need to put out to make the change.

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

Take care,

Bill

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

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

iD8DBQFDJhIBWz+3JHUci9cRAkCjAJwJCChBdL+3yddEuSNfsD0ATNJBlgCeKMp+
0WhbgyeHO97R/qWomGhyktg=
=LpgZ
-----END PGP SIGNATURE-----

--kfjH4zxOES6UT95V--