Messages in this thread | | | Date | Sat, 02 Aug 2008 19:36:15 -0600 | From | Robert Hancock <> | Subject | Re: 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.
| |