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.
> All it knows about are queues (which may be per host or per device
> depending on the implementation). Do we need to introduce the concept
> of something like queue grouping (a sort of lightweight infrastructure
> that could be used by the underlying transport to implement a host
> concept without introducing hosts at the block layer)?
We already have it. Each queue has its lock pointer. If you want to have a
"host" notion, you do it by just setting the queue lock to point to the
host lock (since if they are dependent, you'd _better_ share the lock
between the queues anyway), and then you do
struct myhost_struct *queue_host(struct request_queue *queue)
{
return container_of(queue->queue_lock, myhost_struct, host_lock);
}
and there are no changes necessary to the queue layer.
You can do it other ways too: the "struct kobject" in the queue obviously
contains a pointer to the parent of the queue, and that might well be your
"host" object. Again, exact same deal, except now you'd use
container_of(queue->kobj.parent, myhost_struct, host_kobject);
instead. Entirely up to you.
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)?
Linus
-
: 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
