linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: James Bottomley <jejb@linux.vnet.ibm.com>
Cc: Douglas Gilbert <dgilbert@interlog.com>,
	linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
	linux-api@vger.kernel.org, martin.petersen@oracle.com,
	hare@suse.de, bvanassche@acm.org
Subject: Re: [PATCH v3 00/20] sg: add v4 interface
Date: Mon, 12 Aug 2019 08:23:39 -0700	[thread overview]
Message-ID: <20190812152339.GA15295@infradead.org> (raw)
In-Reply-To: <1565291455.3435.48.camel@linux.vnet.ibm.com>

On Thu, Aug 08, 2019 at 12:10:55PM -0700, James Bottomley wrote:
> Since this will be an extension of something that exists both in your
> sg driver and in the block bsg interface (and thus needs an
> implementation there), I added both linux-block and linux-api to the cc
> (the latter because you're adding to an API).
> 
> Simply extending sg to use the v4 header protocol in uapi/linux/bsg.h
> is fine modulo the code being in the right form.  The problems are the
> new ioctls you want to add that would need to be present there as well.
>  The specific question being how we support async or non-blocking I/O
> on the sg and bsg interfaces.  The standard way we add asynchronous I/O
> is supposed to be via .poll on the file descriptor.  you already use
> read and write in sg and bsg doesn't have a polling interface, but it
> looks like we could use MSG to signal an ioctl is ready to be serviced
> for both.  Would shifting to a non-blocking poll based interface for
> ioctls remove the need to add these SG_IOSUBMIT/SG_IORECEIVE ioctls
> since we could now do everything over blocking or non-blocking SG_IO?

I've spent some wading through this patchset, and it is huge.  I thing
we need to stage it a bit better and split it into multiple.

 1) One (or maybe even multiple) with all the cleanups and minor
    speedups.  That alone is a lot of changes, and will take a while
    to settle
 2) extending the bsg/v4 API to /dev/sg.  I think that is very useful,
    although I need to look at the details a bit more
 3) adding a new async API.  While this seems very useful from the
    theoretical perspective, I really thing the guts need to be in
    common code and then be used by sg and the block device nodes
    (if it happens to be an ioctl).  What worries me a bit there
    is that we have another way to deal with async I/O.  I wonder
    if we can fit this into aio/io_uring somehow.  But I'd rather
    not even thing about that much until we've done all the groundwork.

      parent reply	other threads:[~2019-08-12 15:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190807114252.2565-1-dgilbert@interlog.com>
2019-08-08 19:10 ` [PATCH v3 00/20] sg: add v4 interface James Bottomley
2019-08-08 21:08   ` Douglas Gilbert
2019-08-08 21:37     ` Tony Battersby
2019-08-08 22:25       ` Bart Van Assche
2019-08-09 13:28         ` Tony Battersby
2019-08-08 23:00     ` James Bottomley
2019-08-14  4:19       ` Douglas Gilbert
2019-08-15 17:30         ` Bart Van Assche
2019-08-16 15:59           ` Douglas Gilbert
2019-08-16 17:19             ` Greg KH
2019-08-16 18:10             ` Bart Van Assche
2019-08-16 18:44               ` Douglas Gilbert
2019-08-12 15:23   ` Christoph Hellwig [this message]

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=20190812152339.GA15295@infradead.org \
    --to=hch@infradead.org \
    --cc=bvanassche@acm.org \
    --cc=dgilbert@interlog.com \
    --cc=hare@suse.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /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;
as well as URLs for NNTP newsgroup(s).