Subject: Re: Functional VOP_IOCTL
To: Konrad Schroder <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 02/24/2003 11:24:42
On Mon, 24 Feb 2003, Konrad Schroder wrote:
> On Mon, 24 Feb 2003, Bill Studenmund wrote:
> > While I don't think I mind this change, use an fcntl instead. We added
> > VOP_FCNTL for this type of thing - operations that have more to do with
> > the file system of the vnode than the contents of the vnode. When we add
> > ACL support, we need to start using fcntls, so we might as well get used
> > to it now. :-)
> Well, okay, but looking back over the archives it seems like VOP_FCNTL is
> meant to be even more specific than VOP_IOCTL---it affects the file
> descriptor rather than the file. The things I want to do will affect the
> filesystem as a whole (I mean mount point, not the whole LFS subsystem)
> and in particular they probably will not affect the vnode in hand.
> Really, the operation closest scoped to what I want is mount, but I don't
> think mount flags provide enough flexibility for the sort of operations I
> have in mind.
See the use of F_FSCTL in sys/fcntl.h, _FCNO() & friends, and
_FCNO_FSPRIV() and friends.
The way I look at it is the difference between VOP_IOCTL and VOP_FCNTL is
what happens for device nodes. VOP_FCNTL goes to the file system, while
VOP_IOCTL goes to the device driver. What you want is something that
always goes to the file system, so VOP_FCNTL seems more appropriate (you
never want this call to hit a device driver).
You're right that you really want VFS_IOCTL or some such, which we don't
have. Given that we don't have it, I think VOP_FCNTL is probably the best
Oh, one thing we probably want to do is, by convention, build the "num"
parameters like IOCTLs - the upper 8 bits designate subsystem ('L' for LFS
:-) and the lower 8 bits designate operation. That way something close to
the right thing happens with layered file systems - FCNTLs not in their
subsystem get passed down.