Re: [Fwd: [RFT] major libata update]

[Jeff Garzik <jeff@garzik.org>]

Jens Axboe wrote:
> I think we have a different opinion on what 'optional' is then - because
> things can certainly work just fine the way they current do. And it's
> faster, too.
> 
>> infrastructure, you inevitably wind up with the following code pattern:
>>
>> 	infrastructure code
>> 	send fully prepared request to hardware
>> 	infrastructure code
> 
> But yes, you can make the code nicer for _some_ things with a
> ->queueone() type setup.

That ->queueone() maps the closest to what most hardware appears to 
want: "attempt to push request onto an async hardware queue".

It also enables additional entry points for returning 'device busy' or 
(in SCSI lingo) 'host busy'.  The ability to signal and handle random 
transient conditions like that when hardware resources disappear is easy 
to overlook, but its really powerful.


>> 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.
> 
> The timer is a given, we can't escape that. And the ->queueone() is
> basically hashed out above, no infrastructure changes needed.
> queuecommand_helper would be driver supplied, blk_queuecommand_helper()
> would be a block layer helper. With better names of course, I truly do
> suck at naming functions :-)

Likewise :)

	Jeff