ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)

From: Jeff Garzik (jgarzik_at_pobox.com)
Date: 10/21/05

  • Next message: Greg KH: "Re: Patch: ATI Xilleon port 4/11 Xilleon PCI IDs" 
    Date:	Thu, 20 Oct 2005 20:46:11 -0400
To: andrew.patterson@hp.com

    Andrew Patterson wrote:
    > I believe there is a common understanding that IOCTL's are bad and
    > should be avoided. See:
    >
    > http://lkml.org/lkml/2001/5/20/81

    Yep. Linus's rant here reflects not only his opinion, but general
    consensus, I feel.

    > Yes, CSMI should have had more Linux input when it was developed. The
    > no-new IOCTL policy certainly came as a surprise to the authors. Still,
    > there doesn't seem to be any other usable cross-platform interface that
    > is acceptable to the linux community (or at least to Christoph)'s corner

    Beyond Linus's rant, ioctls have a practical limitation, too: because
    they are untyped, we have to deal with stuff like the 32<->64 compat
    ioctl thunking.

    Consider what an ioctl is, overall: a domain-specific "do this
    operation" interface. Which, further, is nothing but a wrapping of a
    "send message" + "receive response" interface. There are several ways
    to do this in Linux:

    * block driver. a block driver is nothing but a message queue. This is
    why James has suggested implementing SMP as a block driver. People get
    stuck into thinking "block driver == block device", which is wrong. The
    Linux block layer is nothing but a message queueing interface.

    * netlink. You connect to <an object> and send/receive messages. Not
    strictly limited to networking, as this is used in some areas of the
    kernel now for generic event delivery.

    * char driver. Poor man's netlink. Unless its done right, it suffers
    from the same binary problems as ioctls. I don't recommend this path.

    * sysfs. This has no inherent message/queue properties by itself, and
    is less structured than blockdrvr or netlink, so dealing with more than
    one outstanding operation at a time requires some coding.

    sysfs's attractiveness is in its ease of use. It works with standard
    Unix filesystem tools. You don't need to use a library to read
    information, cat(1) often suffices. sysfs, since its normal ASCII
    (UTF8), also has none of the annoying 32<->64 compatibility issues that
    ioctls suffer from.

    Which is best? I don't have a good answer. Largely depends on the
    situation, particularly queueing needs. Networking and storage are
    rapidly converging into "messaging", so the situation is highly fluid in
    any case. Coming from a networking background, I sorta lean towards the
    solution noone has attempted yet: netlink.

    > of it). My personal preference is to hide this stuff in a library, so
    > the kernel implementation is hidden. But even a library needs an
    > underlying kernel implementation.

    Strongly agree here. libc shelters userspace from [most] kernel
    changes, by exporting syscalls in a standard manner. alsa-lib was
    created to shelter userspace from current and future changes in the
    kernel audio interface. libsdi is quite reasonable.

            Jeff

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

  • Next message: Greg KH: "Re: Patch: ATI Xilleon port 4/11 Xilleon PCI IDs"

    Relevant Pages

    • Issues with removable media
      ... simulate the Removable media in a Simple block driver module. ... I am doing the following when trying to simulate the Removable media: ... I prepared an IOCTL to simulate the removable media to the kernel. ...
      (Linux-Kernel)
    • Re: protocol handler for a proprietary protocol
      ... The signature of the ioctl handler is: ... linux kernel, so I would appreciate some clarity on this flow. ... figures if out from the interface name. ... first open socket by calling socke to get the file descriptor fd. ...
      (comp.os.linux.development.system)
    • Re: USB API, ioctls and libusb
      ... > You are supposed to use libusb. ... interface the API that is implemented using URB's inside the kernel). ... The only difference is that libusb uses ioctl and the kernel ...
      (Linux-Kernel)
    • Re: USB API, ioctls and libusb
      ... the program I was trying to fix uses libusb. ... > interface the API that is implemented using URB's inside the kernel). ... It just so happens there is an ioctl() call that provides an URB like ...
      (Linux-Kernel)
    • Re: Sleeping thread not receive signal until it wakes up
      ... of the thread will keep calling IOCTL to get information from the ... kernel and will be blocked if there is no new information. ... and register a SIGALRM handler in the thread by using sigaction. ... the ISR routine when interrupt happens, ...
      (Linux-Kernel)