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 - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
