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
