On 8/8/19 5:08 PM, Douglas Gilbert wrote:
>
> Here is the full set of extra ioctls I have, or will be proposing:
>     SG_IOSUBMIT
>     SG_IOSUBMIT_V3
>     SG_IORECEIVE
>     SG_IORECEIVE_V3
>     SG_IOABORT
>     SG_SG_SET_GET_EXTENDED
>
> They are all new style ioctls using the _IOR(W) macros with fixed size
> objects referenced by the ioctl's third argument. ioctls have been
> referred to as the "garbage bin of Unix". Well that last one is a garbage
> bin within a garbage bin :-) On the plus side, it keeps that list
> relatively short.
>
> Doug Gilbert
>
>
> *** Tony Battersby is a sg driver power user. He has lamented wading through
>      very large logs looking for some hint of why the sg driver is playing
>      up. He has stated the strong preference for more, not less, ioctls.
>
One of the reasons ioctls have a bad reputation is because they can be
used to implement poorly-thought-out interfaces.  So kernel maintainers
push back on adding new ioctls.  But the push back isn't about the
number of ioctls, it is about the poor interfaces.  My advice was that
in general, to implement a given API, it would be better to add more
ioctls with a simple interface for each one rather than to add fewer
extremely complex multiplexing ioctls.

Tony Battersby
Cybernetics

Reply via email to