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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux