On 9/13/05, Bill Studenmund <wrstuden@netbsd.org> wrote:
> On Mon, Sep 12, 2005 at 09:20:13PM +0200, Julio M. Merino Vidal wrote:
> I can think of two reasons. The first is we already have ioctl and fcntl,
> both of which have the ability to handle arbitrary operations. We're now
> proposing a third. Do we really need a third such call?
>=20
> Second, will we be doing one operation, as in statvfs() where we get info=
,
> or will we be doing a sequence of operations? If it's the latter, the
> fcntl() approach is a little easier as we only do path resolution once.
>=20
> Granted, I don't think we will be doing any fs operations which need to
> happen in the fast-path, so it doesn't make a TON of difference, but it
> can be a bit easier to just do the lookup once.
>=20
> HP-UX's fsctl(2) call uses a file descriptor, so we have prior art here.
>=20
> I'm not saying we MUST do this, I just want us to explore it.
>=20
> It could be we want length and command separate, so we do want something
> other than fcntl().

I've just "explored" the fcntl(2) route and it seems suitable for the task.
In fact, it is somewhat easier to add the code because the "framework"
to copyin/copyout parameters of different sizes is already there.  Also,
there is some unused support for file system specific calls, which I've
used to implement this.

I'm not very fond yet on the idea of mixing "file descriptor control
operations" with "general file system operations", but... given that fcntl
is already overloaded with calls that do not operate on a single file
descriptor (M_CLOSEM, M_MAXFD), we could add the functionality there.

I've put an updated patch in place of the other one:

    ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/export.diff

Would be nice if anyone could answer the "XXX-questions" in there (or,
of course, any other stuff that may be incorrect) ;-)

Thanks for all the comments!

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