On Tue, 13 Jul 1999, Charles M. Hannum wrote:

> > The reason for defining the concept of "alternate" semantics in an MI file
> > is that otherwise each fs which wants to do something a little different
> > has to define its own hooks for it.
> 
> Which is exactly *correct*.  Having a single flag that may do
> completely different things depending on the file system is completely
> wrong.

The thought was it's a flag with which you need to know what you're doing.

> > And a specially-trapped ioctl domain isn't a special-case interface? :-)
> 
> No.  It's already done for other things (such as sockets), and the
> interface is specifically designed to support it.

ioctl's on sockets are handled differently because ioctl's go through the
fo_ioctl vector. They aren't special-cased.

> Why add something which is a *flagrant* bastardization of the fcntl(2)
> API when you don't need to?

Flagrant bastardization? fcntl is defined (in syscallargs.h) as taking two
ints and a void *. How is letting some of them hit the fs a
bastardization? They are a part of the command space which isn't used, and
we still leave traditional fcntl's more than enough space to grow (i.e.
2^31 commands).

The thing I really prefer about fcntls over ioctls is what doing this with
ioctl's will do to the vnode interface. Irregardless of how userland
initiates these accesses, we need a new VOP. One, the current ioctl entry,
which varies from files, device nodes, and fifos. The other, what I want
to call fcntl, would be the same for all three (for everyone following the
discussion, see the setup of ffs_vnodeop_entries, ffs_specop_entries, and
ffs_fifoop_entries in sys/ufs/ffs/ffs_vnops.c).

The idea that ioctl(2) calls one for some codes and the other for others
strikes me as one of those sick things Linux does and we all rag on.
That's what I prefered about the fcntl idea. You do a fcntl in userland,
and you enter here. You do an ioctl and you enter there.

Take care,

Bill