Subject: Re: Functional VOP_IOCTL
To: Konrad Schroder <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 02/25/2003 09:52:14
On Mon, 24 Feb 2003, Konrad Schroder wrote:
> On Mon, 24 Feb 2003, Bill Studenmund wrote:
> > See the use of F_FSCTL in sys/fcntl.h, _FCNO() & friends, and
> > _FCNO_FSPRIV() and friends.
> > 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
> Shouldn't the _FCN*_FSPRIV() macros take three arguments, then ---
> subsystem, subsystem-specific command number, and size --- like _IO*()?
Yeah, they should. The subsystem idea came about after having used the
> > the right thing happens with layered file systems - FCNTLs not in their
> > subsystem get passed down.
> Until you mount two unionfss on top of one another and want to affect the
> lower one :^)
unionfs is the only fs where this problem might happen. Everything else
either directly exposes itself (nullfs, umap), or is something that really
doesn't make sense to stack (overlay).
Actually, with unionfs's mount under option, this won't have to be a
problem. You can arrange it so that you have direct access to each of the
Also, probably the best semantics for fcntl (and ioctl) on union mounts is
to steer the op towards the hidden lower mount, the idea being that you
can reach the other underlying fs through the file hierarchy.