Jens Axboe wrote:
On Tue, May 16 2006, Jeff Garzik wrote:
James Bottomley wrote:
On Tue, 2006-05-16 at 12:12 -0400, Jeff Garzik wrote:
Its an API-which-only-libata-uses that we're discussing. And because
its moving to the block layer, its also a
temporary-API-which-only-libata-uses.
OK ... this may be the root of the problem. I really would like libata
to migrate to being block only ... especially as PATA looks to be trying
to follow you into the SCSI subsystem. However, this has been the
statement for the past two years (at least), and really, few
enhancements have been made to block that you need to make good on this.
I think one of the things we'll try to find time to do at the storage
summit is to take a hard look at block to see exactly what has to be
added to make libata solely dependent upon it.
100% agreed...
Ditto! I'd be more than willing to implement some of these features (and
already started to, the per command timeout for instance), but I was
starting to write off libata moving to block as a silly pipe dream in
all honesty... But if momentum is picking up behind this move, then I'll
all for it.
Just gotta be patient. Rome wasn't built in a day, and all that :)
Like I mentioned in another message, the ideal world is that libata uses
an ATA disk driver and a SCSI MMC driver -- just like a modern SAS
controller (which likely supports SATA too) will use both an ATA disk
driver and a SCSI disk driver.
Given this "ideal world", its IMO best that the "storage driver"
infrastructure lives in the block layer not SCSI layer.
The general list, off the top of my head:
* objects: storage message, storage device, storage host, and the
requisite interconnections
Storage message -> request. The rq-cmd-type branch of the block repo has
most/some of that done. For an explicit storage device + host, I have no
plans to expland on what we have.
Agreed that storage message == request.
storage device and storage host are key objects included in the
infrastructure libata uses SCSI for. They fall naturally out of the
infrastructure that provides "device busy", "host busy", EH and EH
synchronization across multiple devices, etc. Though these, SCSI also
provides infrastructure through which an LLDD may export a bus topology
to the user.
* queuecommand-style API
That's a style issue, rather than a required item. You can roll that on
top of the current api by just doing a:
int queuecommand_helper(request_queue_t *q, struct request *rq)
{
/* issue request */
...
return OK/DEFER/REJECT/WHATEVER
}
blk_queuecommand_helper(request_queue_t *q, queue_command_fn *fn)
{
struct request *rq;
int ret;
do {
rq = elv_next_request(q);
if (!rq)
break;
ret = fn(q, rq);
if (ret == OK)
continue;
/* handle replugging/killing/whatever */
} while (1);
}
if you really wanted.
That's not an optional piece. Given the needed timeout / device / host
infrastructure, you inevitably wind up with the following code pattern:
infrastructure code
send fully prepared request to hardware
infrastructure code
At this point I should note that all of what I've been describing is an
_optional addition_ to the block layer. Its all helpers and a few new,
optional structs. This SHOULD NOT involve changing the core block layer
at all. Well, maybe struct request would like the addition of a timer.
But that's it, and such a mod is easy to do.
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
