ioctls

[Andries.Brouwer@cwi.nl]

This night I did some ioctl work, and the longer
one looks at this stuff, the messier it turns out to be.

(i)
First one has the definitions:

#define _IOR(type,nr,size)      _IOC(_IOC_READ,(type),(nr),sizeof(size))
#define _IOW(type,nr,size)      _IOC(_IOC_WRITE,(type),(nr),sizeof(size))

These are really unfortunate. I suppose I'll submit a patch
to change the definition into

#define _IOR(group,nr,argtype)  _IOC(_IOC_READ,(group),(nr),sizeof(argtype))

Really a lot of people have been fooled into believing that
the parameter "size" is a size.  But it is a data type.


(ii)
In all cases where the size is wrong (a largish number of cases),
do we want to define the "correct" ioctls, and leave the old
ones with _OLD suffix as deprecated?


(iii)
For userspace it is difficult to get ioctl definitions.
All the obscure ioctls live in <linux/foo.h> and including
lots of such headers is a sure way to get a source that
doesnt compile. Typedef clashes, things outside #ifdef __KERNEL__
that use things inside, etc etc.
Would anyone object against creating a directory with a
name like kernelapi and slowly moving manifest constants,
ioctl definitions, and definitions of the argument structs
to files there?
This is easy since there is no flag day. File by file things
can be moved, leaving a #include in <linux/foo.h>.
An attempt can be made to keep the namespace under kernelapi clean.
Now userspace can include <kernelapi/foo.h> and __KERNEL__ can disappear.

Andries