Re: ioctl's suck?

[Robert Hancock]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/