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

[Jens Axboe <axboe@suse.de>]

On Wed, May 17 2006, Jeff Garzik wrote:
> 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.

'queue a request' is certainly how most hardware works. The fact is that
->queueone() doesn't enable _anything_ that you cannot already do. In
fact it takes information _away_ from you, since you can no longer peek
at the queue and see if there's one more there for you to issue. The
only selling point for ->queueone() is that it makes it more logical to
structure the code layout for handling the issue.

Which is why I never added this helper. From the block layer
perspective, the driver can only really tell you three things:

- request issued, give me another one
- request not issued, transient error (meaning, call me with this
  request again in the future).
- request not issued, permanent error. kill this request.

A ->queueone() setup deals with returning the right issue error code, a
->queuemany() setup deals with calling the right function for the
condition.

-- 
Jens Axboe