All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	Jens Axboe <axboe@suse.de>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	Tejun Heo <htejun@gmail.com>, Andrew Morton <akpm@osdl.org>
Subject: Re: [Fwd: [RFT] major libata update]
Date: Wed, 17 May 2006 17:41:36 -0400	[thread overview]
Message-ID: <446B9890.7030200@garzik.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0605171036140.10823@g5.osdl.org>

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.

  parent reply	other threads:[~2006-05-17 21:41 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-15 17:08 [Fwd: [RFT] major libata update] Jeff Garzik
2006-05-16 14:18 ` James Bottomley
2006-05-16 15:41   ` Jeff Garzik
2006-05-16 15:51     ` James Bottomley
2006-05-16 16:06       ` Jeff Garzik
2006-05-16 16:30         ` James Bottomley
2006-05-16 16:39           ` Jeff Garzik
2006-05-16 21:55             ` Luben Tuikov
2006-05-16 21:32           ` Luben Tuikov
2006-05-16 16:08       ` Tejun Heo
2006-05-16 16:13         ` Tejun Heo
2006-05-16 16:29         ` James Bottomley
2006-05-16 16:37           ` Jeff Garzik
2006-05-16 16:39           ` Tejun Heo
2006-05-16 16:50             ` James Bottomley
2006-05-16 17:07               ` Tejun Heo
2006-05-16 17:09                 ` Jeff Garzik
2006-05-16 19:58                 ` Christoph Hellwig
2006-05-16 20:02                   ` Jeff Garzik
2006-05-16 21:28                   ` James Bottomley
2006-05-18  3:27                     ` Tejun Heo
2006-05-19 12:07                       ` [PATCH] SCSI: make scsi_implement_eh() generic API for SCSI transports Tejun Heo
2006-05-16 16:12       ` [Fwd: [RFT] major libata update] Jeff Garzik
2006-05-16 16:38         ` James Bottomley
2006-05-16 16:57           ` Jeff Garzik
2006-05-17  7:37             ` Jens Axboe
2006-05-17 15:06               ` Jeff Garzik
2006-05-17 15:50                 ` James Bottomley
2006-05-17 15:58                   ` James Smart
2006-05-17 16:17                   ` Jeff Garzik
2006-05-17 17:53                     ` James Bottomley
2006-05-17 22:08                       ` Jeff Garzik
2006-05-17 22:15                         ` Jeff Garzik
2006-05-17 17:47                   ` Linus Torvalds
2006-05-17 17:55                     ` Jens Axboe
2006-05-17 22:04                       ` Linus Torvalds
2006-05-17 22:12                         ` Jeff Garzik
2006-05-17 21:41                     ` Jeff Garzik [this message]
2006-05-17 21:52                     ` Douglas Gilbert
2006-05-17 22:20                       ` Linus Torvalds
2006-05-18  3:04                     ` Luben Tuikov
2006-05-17 16:05                 ` Douglas Gilbert
2006-05-17 17:37                 ` Jens Axboe
2006-05-17 21:58                   ` Jeff Garzik
2006-05-18  7:21                     ` Jens Axboe
2006-05-16 18:28       ` Luben Tuikov
2006-05-16 18:15     ` Luben Tuikov
2006-05-16 18:05   ` Luben Tuikov
2006-05-16 18:38     ` James Bottomley
2006-05-16 22:24       ` Luben Tuikov
2006-05-16 22:29         ` James Bottomley
2006-05-16 23:02           ` Luben Tuikov
2006-05-16 23:12             ` James Bottomley
2006-05-17  0:25               ` Luben Tuikov
2006-05-17 14:09                 ` James Bottomley
2006-05-18  2:39                   ` Luben Tuikov
2006-05-18 13:57                     ` James Bottomley
2006-05-19  3:28                       ` Luben Tuikov
2006-05-17 14:02               ` missed patch: Block I/O while SG reset operation in progress James Smart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=446B9890.7030200@garzik.org \
    --to=jeff@garzik.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.