> > 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.

That's great.  So why even bother naming it?  After all; it's just a
magic flag.  That train of logic leads only downward.

> > 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.

Oh, really?

        /*
         * Interface/routing/protocol specific ioctls:
         * interface and routing ioctls should have a
         * different entry since a socket's unnecessary
         */
        if (IOCGROUP(cmd) == 'i')
                return (ifioctl(so, cmd, data, p));
        if (IOCGROUP(cmd) == 'r')
                return (rtioctl(cmd, data, p));
        return ((*so->so_proto->pr_usrreq)(so, PRU_CONTROL,
            (struct mbuf *)cmd, (struct mbuf *)data, (struct mbuf *)0, p));  

Looks to me like that code path does exactly what I'm talking about.
Indeed, one might even infer that was the entire reason for having the
ioctl(2) `groups' to begin with.  (Or one could just RTFB.)

> 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).

That's at best hand-waving.  You're not merely `letting some of them
hit the fs'; you're specifically changing the fcntl(2) API to emulate
ioctl(2).  If you want ioctl(2), then use ioctl(2).

> The thing I really prefer about fcntls over ioctls is what doing this with
> ioctl's will do to the vnode interface.

That's ridiculous.  You're adding a new vnode op already; calling it
by a different name makes no difference.