Re: ioctls

Re: ioctls

[Pete Zaitcev]

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

Great idea! I actualy wanted it changed too, but could not find
two suitable English words. Perhaps that's why Linus blew it.
Wait... you aren't a native speaker either? :-)  Anyway, I like it.
Just about anything is better than what we have now.

> (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?

I would not touch anything, but add a comment near every
instance (/* THIS IS BROKEN DOUBLE sizeof, DO NOT COPY */).

> (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?

There was a more comprehensive idea floated by Chrishtoff
Hellwig last week. We ought to ask Arjan (or find someone
else) to maintain glibc-kernelheaders as a community tarball
at kernel.org somewhere. Please, don't look at me. OK, only
if Arjan _REALLY_ refuses... Or perhaps you want to take
it yourself? This is basically your idea, only halfway
done: everything is copied already. Also, we do not need
a buy-in from Linus (though I suspect he'd support it).

-- Pete

Re: ioctls

[Arjan van de Ven]

On Wed, Apr 09, 2003 at 01:06:04AM -0400, Pete Zaitcev wrote:
> > ioctl definitions, and definitions of the argument structs
> > to files there?
> 
> There was a more comprehensive idea floated by Chrishtoff
> Hellwig last week. We ought to ask Arjan (or find someone
> else) to maintain glibc-kernelheaders as a community tarball
> at kernel.org somewhere. Please, don't look at me. OK, only
> if Arjan _REALLY_ refuses... Or perhaps you want to take
> it yourself? This is basically your idea, only halfway
> done: everything is copied already. Also, we do not need
> a buy-in from Linus (though I suspect he'd support it).

I have no problem with making the reduced headerset more generically
available (and then clean it up more etc etc); it needs for more people
than just me to care to make it worth it though.

Re: ioctls

[Andries.Brouwer]

> maintain glibc-kernelheaders as a community tarball
> at kernel.org somewhere.

Maintaining that separately would be a large amount of work.
Work that is never finished.

Splitting up the kernel headers is also a large amount of work,
but after a finite amount of time it will have been done.

ioctls

[Andries.Brouwer]

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

IOCTLS

[Prasad]

first of all i am sorry to post this message here without actually knowing
if this could be asked here...

Where can i find the documentation about ioctls, specially the ioctls
listed in asm/ioctls.h

Thanks in advance

Prasad<prasad_s@gdit.iiit.net>