Linus Torvalds wrote:
On Wed, 17 May 2006, James Bottomley wrote:
This is one of the questions. Currently block has no concept of "host".
That's good.
I don't understand why you'd ever _want_ a concept of "host". The whole
concept is broken and unnecessary. At no point should you even need to map
from request to host, but if you do, you don't need to introduce any
generic "host" notion, you can do it easily per-queue.
"host" is ultimately the wrong word, sure.
It's more about (a) grouping queues into a topology that the user
expects, as exported by sysfs, and (b) grouping queues for the purposes
of useful and/or necessary hardware operations like "stop <these>
queues, so that we can bitbang the hardware".
That grouping of queues, along with the lib-ification of highly common
request management code[1], is part of the non-SCSI utility that libata
derives from drivers/scsi.
"group-wide operations" are highly common, and generic code inevitably
results from that. But IMO that's helper code, living on top of the
perfectly-fine existing code.
The whole fixation with "host" in the SCSI layer is a bug, I think. What
does it matter, really? And when do you actually have a "request_queue"
entry without already knowing which controller it is connected to (ie why
do you even need that mapping)?
True, the mapping is obtained from request_queue not request.
The entry point into a block driver is via q->request_fn(), which only
has a request_queue for an argument. So in practice, one usually
obtains the private controller-info and bus-info data via the
request_queue's ->queuedata.
Deep into sub-APIs, I've seen that sometimes you'll see only the request
passed as an argument, because it's easier to walk
request->queue->controller_info than to pass additional arguments to
every function.
Jeff
[1] "resource management": refers to drivers/scsi's handling of 'device
busy', 'group-of-queues busy' style transient errors, well integrated
with block layer's command queueing and well synchronized with the EH
thread.
-
: 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
