James Bottomley wrote:
On Wed, 2006-05-17 at 12:17 -0400, Jeff Garzik wrote:
Yes, and not only that... you must describe the queue pipeline too.
i.e. N logical devices can be bottlenecked behind a bridge (expander,
port multiplier, tunnel) of queue depth Q, which may in turn be behind
another bottleneck. :)
Well ... no, I'm not convinced of this. Block is currently a nice, fast
abstraction. It's designed to manage storage infrastructure and provide
helpers to implementation. The question is how much more common
infrastructure do we need to slim down all of our storage stacks. I.e.
block provides the building blocks to allow the storage implementation
to do what it wants, but it doesn't necessarily provide the full
implementation.
My central thesis is that
* SCSI provides a generic _storage driver_ infrastructure, encapsulating
many common idioms generic to SCSI and non-SCSI hardware alike.
* Any such storage driver infrastructure, outside of SCSI, should impose
no burdens on existing block drivers.
Call such storage driver infrastructure "libstorage" if you will.
But overall, libata and SAS controllers are forced to deal with the
reality of the situation: they all wind up either using, or recreating
from scratch, objects for host/device/bus/etc. in order to sanely allow
all the infrastructure to interoperate.
but that doesn't go for all storage ... look at the way usb and firewire
implement host in SCSI at the moment.
Let's just stop using the word host, its too confusing for all involved
:) I'm well aware of this, look at how libata uses Scsi_Host too...
You'll all note that struct Scsi_Host and struct scsi_cmnd have very
little to do with SCSI. Its almost all infrastructure and driver
management. That's the _useful_ stuff that libata uses SCSI for.
Some is driver management, others are SCSI specific. We'll never get
Agreed, though IMO I claim that "a lot" is driver management.
away from the need for Scsi_Host and scsi_cmnd, but we can make sure
they contain only truly SCSI specific pieces. scsi_cmnd is the closest
since it pretty much has a one to one mapping with a block request.
Agreed.
Thus, moving libata to the block layer entails either
s/Scsi_Host/Storage_Host/g or a highly similar infrastructure, to
achieve the same gains.
I'm not sure. Block is currently nicely lightweight. A large number of
implementations have no use for a host concept ... I don't think we
should be forcing it on them.
Like I said above, think "libstorage". I think block as-is, too.
Jeff
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
