linux-kernel - Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201603102019.32467.arnd@arndb.de>
Date:	Thu, 10 Mar 2016 20:19:32 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	ygardi@...eaurora.org
Cc:	"Greg KH" <gregkh@...uxfoundation.org>,
	james.bottomley@...senpartnership.com,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, santoshsy@...il.com,
	linux-scsi-owner@...r.kernel.org,
	"Dolev Raviv" <draviv@...eaurora.org>,
	"Gilad Broner" <gbroner@...eaurora.org>,
	"Vinayak Holikatti" <vinholikatti@...il.com>,
	"James E.J. Bottomley" <jbottomley@...n.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	"Michael Neuling" <mikey@...ling.org>,
	"Matthew R. Ochs" <mrochs@...ux.vnet.ibm.com>,
	"Wen Xiong" <wenxiong@...ux.vnet.ibm.com>,
	"Subhash Jadavani" <subhashj@...eaurora.org>,
	"open list:ABI/API" <linux-api@...r.kernel.org>
Subject: Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

On Thursday 10 March 2016, Arnd Bergmann wrote:
> On Wednesday 09 March 2016, ygardi@...eaurora.org 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