From: James Bottomley <James.Bottomley@SteelEye.com>
To: Douglas Gilbert <dougg@torque.net>
Cc: Mike Christie <michaelc@cs.wisc.edu>,
device-mapper development <dm-devel@redhat.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
Jens Axboe <axboe@suse.de>
Subject: Re: [PATCH RFC 0/4] use scatter lists for all block pc requests and simplify hw handlers
Date: Mon, 06 Jun 2005 09:19:03 -0500 [thread overview]
Message-ID: <1118067544.5045.17.camel@mulgrave> (raw)
In-Reply-To: <42A3E275.6030106@torque.net>
Well ... while I've got your attention, the only complexity I see to
converting sg is the hd->iovec_count != 0 case, which is doing vectored
SG from user land.
This can be implemented (basically you do multiple bio attachment to a
request), and probably in the block layer (since block SG_IO would then
pick up the capability).
How important is this functionality? Are there any applications using
it?
On Mon, 2005-06-06 at 15:43 +1000, Douglas Gilbert wrote:
> There is no max_length on sense_buffer. How does one
> know how much, if any, sense data was written (returned).
Well, given the way most initiators work we can't do variable length
sense buffer sizes; it's limited by SCSI_SENSE_BUFFERSIZE, which seems
to be a good fixed value assumption. The reason we don't have this is
because the block layer doesn't. It also assumes SCSI_SENSE_BUFFERSIZE
is the correct maximum.
> resid is a very useful return parameter.
Yes, I spotted that too ... already in my version II ...
> Perhaps the *done() callback should have
> two more arguments (and scsi_do_command()
> one more argument). And 'buffer' and 'bufflen' have
> not changed in name but I assume they have in nature.
>
> Additionally perhaps it is time to start thinking about
> a clean pass through. Something that can pass a packet
> command (like sg can at the moment) but to a scsi_host
> (or a transport host). An additional argument would be
> needed to pass addressing information to the LLD. I'm
> thinking about the SAS Serial Management Protocol (SMP)
> that has nothing to do with the block layer or the
> SCSI mid level. We want to bind to a SAS host (initiator
> port) and supply a SAS address (of the SMP target
> which is most likely an expander).
Well, pretty much the block layer SG_IO is a clean passthrough. The
direction I think it makes most sense to move in is towards services
provided by the block layer (even if that means additions to it) rather
than away from them. Even for arbitrary SAS expanders, we can detect
and bind to them; once that's done we have a connection and a management
application can read and set sysfs parameters for the object.
James
next prev parent reply other threads:[~2005-06-06 14:19 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-04 1:19 [PATCH RFC 0/4] use scatter lists for all block pc requests and simplify hw handlers Mike Christie
2005-06-04 16:07 ` James Bottomley
2005-06-05 7:15 ` Mike Christie
2005-06-05 9:41 ` [dm-devel] " christophe varoqui
2005-06-06 13:31 ` Lars Marowsky-Bree
2005-06-07 0:04 ` Michael Christie
2005-06-07 7:01 ` [dm-devel] " Lars Marowsky-Bree
2005-06-05 14:40 ` James Bottomley
2005-06-05 19:11 ` James Bottomley
2005-06-06 5:43 ` Douglas Gilbert
2005-06-06 14:19 ` James Bottomley [this message]
2005-06-07 13:08 ` Douglas Gilbert
2005-06-07 13:34 ` Tony Battersby
2005-06-07 16:34 ` James Bottomley
2005-06-07 18:38 ` [PATCH RFC 0/4] use scatter lists for all blockpc " Tony Battersby
2005-06-07 18:43 ` Jens Axboe
2005-06-07 15:59 ` [PATCH RFC 0/4] use scatter lists for all block pc " James Bottomley
2005-06-07 18:07 ` Jens Axboe
2005-06-07 19:26 ` James Bottomley
2005-06-08 7:09 ` Jens Axboe
2005-06-06 19:02 ` Patrick Mansfield
2005-06-07 15:26 ` Michael Christie
2005-06-07 18:23 ` Patrick Mansfield
2005-06-08 15:41 ` Mike Christie
2005-06-09 0:08 ` Patrick Mansfield
2005-06-09 6:18 ` Jens Axboe
2005-06-09 11:51 ` James Bottomley
2005-06-09 11:54 ` Jens Axboe
2005-06-07 12:10 ` Christoph Hellwig
2005-06-07 12:20 ` James Bottomley
2005-06-07 15:36 ` Michael Christie
2005-06-07 15:45 ` [dm-devel] " Michael Christie
2005-06-07 16:26 ` Kai Makisara
2005-06-07 19:23 ` James Bottomley
2005-06-07 18:09 ` Jens Axboe
2005-06-08 12:46 ` Mike Christie
2005-06-07 18:07 ` Jens Axboe
2005-06-07 19:38 ` James Bottomley
2005-06-08 3:00 ` Douglas Gilbert
2005-06-08 12:59 ` James Bottomley
2005-06-08 14:50 ` Luben Tuikov
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=1118067544.5045.17.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=axboe@suse.de \
--cc=dm-devel@redhat.com \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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