On Thu, Jan 12, 2017 at 05:28:45PM -0500, Mike Snitzer wrote:
> What is "incomplete" about request-based DM's BLOCK_PC support?

BLOCK_PC requests are always aomething issued by the driver itself
(for a broad defintion of the driver, aka everything under the block
layer that works together is a driver for this purpose, e.g. all
of the SCSI subsystem).  If a driver doesn't issue BLOCK_PC
requests itself or through library functions only called from the
driver (e.g. scsi_cmd_ioctl) it is incomplete because it can't
be used.

> I'm also missing how you're saying the new blk-mq request-based DM will
> work with your new model.  I appreciate that we get the request from the
> underlying blk-mq request_queue and it'll be properly sized.  But
> wouldn't we need to pass data back up for these SCSI pass-through
> requests?  So wouldn't the top-level multipath request_queue need to
> setup cmd_size?

As said above - supporting BLOCK_PC for dm does not make sense, as
it's an internal passthrough mechanism for driver internal use.
It just happened we standardized it at the block layer because SCSI
commands are a standard supported by a few different drivers, e.g.
SCSI itself, the old ide code for ATAPI and CCISS and virtio_blk
which primarily are block drivers but allow some SCSI passthrough.

To be honest I'd love to just fold BLOCK_PC into the SCSI layer sooner
or later - the old IDE code and CCISS should die off sooner or later,
and virtio_blk scsi passthrough was a horrible idea to start with
(and I say that as the person who had the idea back then and implemented

> Sorry for the naive questions (that clearly speak to me not
> understanding how this aspect of the block and SCSI code work).. but I'd
> like to understand where DM will be lacking going forward.

At least in terms of BLOCK_PC nothing will change for dm, the code
was simply dead on arrival.  Maybe I should change the subject
to say that more clearly.
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to