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.
> 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.
> * 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.
> * EH thread(s)
> * timers, for command timeouts
Agree, we can abstract out the grunt handling of timeouts and the
context required in the block layer.
> * SCSI-style MLqueue and state stuff, i.e. ability to return "device
> busy", "host busy", "retry this command", ...
Comes with the blk_queuecommand_helper() type setup from above.
> And once libata is happy at the block layer, move SCSI to using this
> stuff too :)
Definitely.
--
Jens Axboe
-
: 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
