Re: [PATCH v3 00/20] sg: add v4 interface

[Tony Battersby <tonyb@cybernetics.com>]

On 8/8/19 6:25 PM, Bart Van Assche wrote:
> On 8/8/19 2:37 PM, Tony Battersby wrote:
>> On 8/8/19 5:08 PM, Douglas Gilbert wrote:
>>> *** 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.
> Hi Tony,
>
> What is your motivation to use the SG_IO API? Is it controlling SMR 
> drives or are you using SG_IO for another reason? I'm asking because 
> depending on the use case there may be a better solution than using the 
> SG_IO API.
>
> Thanks,
>
> Bart.
>
Actually I used the asynchronous write()/read()/poll() sg interface to
implement RAID-like functionality for tape drives and medium changers,
in a commercial product that has been around since 2002.  These days our
products use a lot more disk I/O than tape I/O, so I don't write much
new code using the sg interface anymore, although that code is still
there and has to be maintained as needed.  So I don't have any immediate
plans to use any of the new sgv4 features being introduced, and
unfortunately I am way too busy to even give it a good review...

Tony Battersby
Cybernetics