[lkml]   [2008]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ioctl's suck?
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.

 \ /
  Last update: 2008-08-03 03:39    [W:0.026 / U:5.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site