public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: ygardi@codeaurora.org
Cc: "Greg KH" <gregkh@linuxfoundation.org>,
	james.bottomley@hansenpartnership.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, santoshsy@gmail.com,
	linux-scsi-owner@vger.kernel.org,
	"Dolev Raviv" <draviv@codeaurora.org>,
	"Gilad Broner" <gbroner@codeaurora.org>,
	"Vinayak Holikatti" <vinholikatti@gmail.com>,
	"James E.J. Bottomley" <jbottomley@odin.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Michael Neuling" <mikey@neuling.org>,
	"Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>,
	"Wen Xiong" <wenxiong@linux.vnet.ibm.com>,
	"Subhash Jadavani" <subhashj@codeaurora.org>,
	"open list:ABI/API" <linux-api@vger.kernel.org>
Subject: Re: [PATCH v7] scsi: ufs: add ioctl interface for query request
Date: Thu, 10 Mar 2016 20:19:32 +0100	[thread overview]
Message-ID: <201603102019.32467.arnd@arndb.de> (raw)
In-Reply-To: <201603101818.33826.arnd@arndb.de>

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

  reply	other threads:[~2016-03-10 19:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09 14:11 [PATCH v7] scsi: ufs: add ioctl interface for query request Yaniv Gardi
2016-03-09 16:29 ` Greg KH
2016-03-09 19:09   ` ygardi
2016-03-10 17:18     ` Arnd Bergmann
2016-03-10 19:19       ` Arnd Bergmann [this message]
2016-03-11  1:43         ` Martin K. Petersen
2016-03-11  8:45           ` Hannes Reinecke
2016-03-13 12:45             ` Winkler, Tomas
2016-03-09 19:09   ` ygardi
2016-03-09 20:18     ` Greg KH
2016-03-09 20:52       ` ygardi
2016-03-09 22:47         ` Greg KH
2016-03-10 15:52           ` ygardi
2016-03-10 16:24             ` Greg KH
2016-03-10 16:29               ` ygardi
2016-03-10 16:39                 ` Greg KH
2016-03-10 18:48                   ` ygardi
2016-03-10 18:58                     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201603102019.32467.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=draviv@codeaurora.org \
    --cc=gbroner@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=jbottomley@odin.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi-owner@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mikey@neuling.org \
    --cc=mrochs@linux.vnet.ibm.com \
    --cc=santoshsy@gmail.com \
    --cc=subhashj@codeaurora.org \
    --cc=vinholikatti@gmail.com \
    --cc=wenxiong@linux.vnet.ibm.com \
    --cc=ygardi@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox