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
