Re: ioctl's suck?

[Robert Hancock <hancockr@shaw.ca>]

Brian Beattie wrote:
> The other day Linus (I think) made the statement, that I don't disagree
> with, that I will parapharse as "ioctl's suck".  If I recall correctly
> and understand he was saying that a device that uses ioctls is broken.
> (this is my paraphrase and if it offends anybody it is my fault not the
> original author's).
> 
> This got me to thinking about a device driver that I'm working on.
> Currently I have some ioctls to handle status and out of band messages
> and I'm wondering about eliminating the ioctls.  I'm wondering if
> anybody has any ideas or opinions that they would like to share, about
> just what i wrong with ioctls and/or how to avoid them.

As I see it the main problems are:

-Unless the ioctl parameter structures are laid out carefully, you end 
up with problems like different structure layouts between 32/64-bit 
processes, etc.

-They can't really be used by anything other than a C or C++ program. 
Anything else (shell script, Python, Java, etc.) is pretty much out of 
luck unless it can use a C shim layer of some sort.

> 
> I can see a number of problems with ioctls that I can'tr quite put into
> words.
> 
> I could add a control device and pass ascii strings for status and OOB
> messages, would that be an improvement?

Quite likely. For something like a status that's being read out of the 
device, a sysfs file would seem a more logical choice. If you're sitting 
there waiting for messages to show up, though, a separate device node 
might be better.