On Wed, Mar 09, 2016 at 08:52:59PM -0000, ygardi@xxxxxxxxxxxxxx wrote: > > On Wed, Mar 09, 2016 at 07:09:49PM -0000, ygardi@xxxxxxxxxxxxxx wrote: > >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote: > >> >> This patch exposes the ioctl interface for UFS driver via SCSI device > >> >> ioctl interface. As of now UFS driver would provide the ioctl for > >> query > >> >> interface to connected UFS device. > >> >> > >> >> Reviewed-by: Subhash Jadavani <subhashj@xxxxxxxxxxxxxx> > >> >> Signed-off-by: Dolev Raviv <draviv@xxxxxxxxxxxxxx> > >> >> Signed-off-by: Gilad Broner <gbroner@xxxxxxxxxxxxxx> > >> >> Signed-off-by: Yaniv Gardi <ygardi@xxxxxxxxxxxxxx> > >> > > >> > What tool is going to use this ioctl? Why does userspcae want to do > >> > something "special" with UFS devices? Shouldn't they just be treated > >> > like any other normal block device? > >> > > >> > >> 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. > > > > But do you want to do with that information? Why does userspace care? > > > > i don't really understand the subtext of your question - > as ANY ioctl cb, we decided to implement the ioctl callback of this scsi > device in order to get information like UNIT DESC, DEVICE DESC, FLAGs, > ATTRIBUTES. > When dealing with UFS devices, one should be able to read the > characteristics of the device. why ? well, why not ? Why aren't those characteristics just exported as sysfs attributes under control by the UFS controller driver? Why do you need/want an ioctl for this? > during development of this driver, it was useful in many cases to be able > to communicate with the device, by simple IOCTL command, rather than > implementing ad-hock. Do other storage busses have these types of "custom" ioctls for their bus-type alone? For simple attributes like this, shouldn't you be using sysfs instead so that it is much easier for userspace tools to get access to them? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
