[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.020 / U:58.728 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site