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
-
: 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
