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

> > For the flag changes, I'd add O_ALT_IO and O_OTHER (other is droppable if
> > objectionalbe). These flags can be set at open or via F_SETFL. They would
> > correspond to FALTIO and FOTHER for kernel-internal flags. Add
> > IO_ALTSEMANTICS and IO_OTHER flags to i/o flags passed to
> > VOP_READ & VOP_WRITE. vn_read() and vn_write() would set these flags
> > (respectivly) if the F flags were set for the file.
> 
> I see no well-defined meaning for what these flags do.  As such, it
> seems highly inappropriate to add them.

IO_ALTSEMANTICS, as Jason mentioned, has an fs-defined meaning. Exactly
what an fs considers "alternate" semantics is up to it.

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.

> > If bit (int)0x80000000 (F_FORFS) is set, we process the fcntl in an
> > ioctl-ish fashon. F_C_VOID, F_C_OUT, and F_C_IN (0x40000000, 0x20000000, &
> > 0x10000000 respectivly) specify if the call passes in no structure (void),
> > passes out a struct, and/or passes in a struct. Exactly as for an ioctl.
> 
> Why don't you just add a separate ioctl(2) domain which is trapped and
> passed to the backing file system?  This is a no-brainer.  There's no
> reason to create another special-case interface.

And a specially-trapped ioctl domain isn't a special-case interface? :-)

Also, even if we define two domains, one a NetBSD-defined namespace and
the other the fs-specific one, we only have 256 commands. While that seems
a lot, it strikes me as a stop-gap measure.

We're going to have to add an extra VOP (so that these operations on
device and fifo nodes go to the fs). Why add something which looks easy to
out grow?

Take care,

Bill