> >> Is this format for 'request' enforced anywhere in NetBsd, or is
> >> it just a convention?
> >
> >Well, this is used to copy the argument between kernel and user space. So
> >if you don't follow it, be sure to mark the ioctl as IOC_VOID.
> >
> More explicitly -- a higher layer of the kernel than the individual 
> device driver does the copyin/copyout for ioctl arguments.  If you want 
> to use that mechanism -- and in my opinion you'd need really strong 
> justification to do anything else -- you have to abide by the format.

I asked the question in order to determine what NetBSD did,
maybe I could have read the source.  But generally the system
call entry code isn't the lightest of reading :-)

The actual problems arise trying to port (or run) programs (and
probably device drivers) written for systems that do not have
this 'restriction' on the value of arguments to ioctl().

We (ie a company I used to work for) found that using ioctl
commands of the form ('x' << 8 | cmd) didn't give adequately
unique numbers because most values for 'x' were already taken.
This was particularly important with a multi layer driver
structure where the request is passed down the IO system until
recognosed by a driver (ie Streams based comms protocol stacks)

ISTM that when 'int' went from 16bit to 32bit someone decided
to introduce a 'horrid hack' to pass extra information through
the ioctl() function - instead of introducing a system call that
had the required set of parameters (fd, cmd, IN|OUT, buff, len).

	David