On Thursday 10 March 2016, Arnd Bergmann wrote: > On Wednesday 09 March 2016, ygardi@xxxxxxxxxxxxxx wrote: > > Any userspace application can be a tool. > > We already implemented and used a user space application, that sent > > queries to the UFS devices in order to get information and descriptors. > > Not only ioctl interface is a useful way to interact with the device, > > we used it, and found it very helpful in varies cases. > > hence, this patch. > > This patch has been already addressed all comments of Arnd Bergman from 5 > > months ago, and now, re-uploaded again. > > Do you have a pointer to that review? It's been a long while, so I > have completely forgotten what issues I raised and how it got resolved. I got your link in private message and read up on it again now. To clarify: I commented on the formal API definition, and you indeed addressed all my concerns, so this is now an ioctl command that follows our usual calling conventions. However, this is orthogonal to the question of whether it is a good idea to have this interface implemented as an ioctl as asked by Greg, and who is actually using it. I'm lacking the detailed subsystem knowledge to answer this, but I note that other block drivers have similar passthrough interfaces. Looking through what other drivers do, I've found a couple of patterns now. n particular, most use the SG_IO ioctl to pass down commands from user space into a device specific command queue. Have you looked at that interface in the past to see if it would fit your use case? There is also a 'bsg' API that some drivers implement, which I think would be another alternative. Could any of the SCSI experts comment on what they expect a driver to use out of those three alternatives (if any): * private ioctl * bsg * sg_io Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
