From: Boaz Harrosh <openosd@gmail.com>
To: dgilbert@interlog.com,
SCSI development list <linux-scsi@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
James Bottomley <JBottomley@parallels.com>
Subject: Re: [PATCH v2] sg: add SG_FLAG_Q_AT_TAIL flag
Date: Thu, 05 Jun 2014 18:27:02 +0300 [thread overview]
Message-ID: <53908C46.8080308@gmail.com> (raw)
In-Reply-To: <538F3416.5090306@interlog.com>
On 06/04/2014 05:58 PM, Douglas Gilbert wrote:
> When the SG_IO ioctl was copied into the block layer and
> later into the bsg driver, subtle differences emerged.
>
> One difference is the way injected commands are queued through
> the block layer (i.e. this is not SCSI device queueing nor SATA
> NCQ). Summarizing:
> - SG_IO in the block layer: blk_exec*(at_head=false)
> - sg SG_IO: at_head=true
> - bsg SG_IO: at_head=true
>
> Some time ago Boaz Harrosh introduced a sg v4 flag called
> BSG_FLAG_Q_AT_TAIL to override the bsg driver default.
> This patch does the equivalent for the sg driver.
>
Yep
>
> ChangeLog:
> Introduce SG_FLAG_Q_AT_TAIL flag to cause commands
> to be injected into the block layer with
> at_head=false.
>
> Changes since v1:
> Make guard condition (only take sg v3 interface or later
> invocations) clearer.
>
> Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
>
Douglas Hi
Please I'm just curious? up until now all application users
used "SG_FLAG_Q_AT_HEAD". Therefor I deduce that you guys
came across a new application that can make use of the new
SG_FLAG_Q_AT_TAIL facility.
What was the application's writer considerations for using
the old sg interface and not use the newer bsg interface
that already has this support. For me I can see 2 main areas
that I find bsg missing.
1. aio "scatter_gather" type io.
(ie multiple pointers multiple length buffers that are
written / read from same linear range on device)
[The async aspect of aio can be implemented via bsg
with the write+read system calls]
2. mmap of direct device range to user vm memory
Which of these, or other, considerations where cardinal
in using of the old interface in new code?
(For me personally both above shortcomings are very
much missed]
Thanks
Boaz
next prev parent reply other threads:[~2014-06-05 15:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 14:58 [PATCH v2] sg: add SG_FLAG_Q_AT_TAIL flag Douglas Gilbert
2014-06-05 9:24 ` Christoph Hellwig
2014-06-05 15:27 ` Boaz Harrosh [this message]
2014-06-05 17:16 ` Jeremy Linton
2014-06-05 22:09 ` Douglas Gilbert
2014-06-11 14:54 ` Ewan Milne
2014-06-11 21:14 ` Mike Christie
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=53908C46.8080308@gmail.com \
--to=openosd@gmail.com \
--cc=JBottomley@parallels.com \
--cc=dgilbert@interlog.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.