linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <jejb@steeleye.com>
To: Luben Tuikov <luben_tuikov@adaptec.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] minimal SAS transport class
Date: Fri, 26 Aug 2005 12:22:40 -0500	[thread overview]
Message-ID: <1125076960.5079.61.camel@mulgrave> (raw)
In-Reply-To: <430F46AA.2050305@adaptec.com>

On Fri, 2005-08-26 at 12:43 -0400, Luben Tuikov wrote:
> > A move away from forced HCIL addressing would be a good thing.
> > 
> > However, its impossible to completely move away from addressing, as 
> > userspace and the SCSI core need ways to route CDBs to devices based on 
> > address.
> 
> They can use _anyone_ label in the label list of the LU.

I think what Jeff means is that the mid-layer needs to know which LLD to
send the CDB to.  This is the routing information (and is really just
the host number).  The LLD takes the rest of the information to work out
where it's sending the CDB.  For SPI this is often just PUN and LUN.
For FC it's usually WWPN and LUN.  Currently the information we send
down is the endpoint, represented by the scsi_device.

> The label itself is opaque to SCSI Core.  It may mean something
> to users, it may mean something to the protocol layer, but to
> SCSI Core it is completely opaque, and SCSI Core should _not_
> try to interpret it/them.

Labelling devices is policy.  That's the bit we're trying to push up to
the user via tools like udev.  The routing information we need is
already inherent in the structure of the scsi generic device tree. So,
by and large, the mid layer doesn't care what the numbers contained
within the struct scsi_device are.  It just uses a scsi_device to send a
CDB.  The LLDs however, do care.  SPI LLDs want to find channel, id
(target) and lun numbers.  FC drivers map id to wwpn internally and so
would probably quite like a way of sticking the wwpn into the id instead
of having a fictitious number.

The point is that labels are user policy and managed at user level.  The
representations used in the generic device tree shows what the kernel
actually uses and should be the preferred form for the transport.

So what's really needed is a scheme that allows the LLDs to use the id
transparently without having to map it to what they really want while
not breaking all the current SPI users (or which patches up every SPI
driver).

James



  reply	other threads:[~2005-08-26 17:23 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-20  4:15 [PATCH] minimal SAS transport class James.Smart
2005-08-20  4:57 ` Jeff Garzik
2005-08-20 17:23 ` Luben Tuikov
2005-08-21 17:03   ` Christoph Hellwig
2005-08-21 16:52 ` Christoph Hellwig
2005-08-21 18:23   ` Luben Tuikov
2005-08-22  4:55 ` Matt Domsch
2005-08-22 17:05   ` Luben Tuikov
2005-08-22 21:53     ` Mike Anderson
2005-08-23 23:55       ` Luben Tuikov
2005-08-24 17:12         ` Patrick Mansfield
2005-08-24 20:05           ` Luben Tuikov
2005-08-24 20:42             ` Patrick Mansfield
2005-08-24 21:48               ` Luben Tuikov
2005-08-23 11:10     ` Douglas Gilbert
2005-08-23  6:27 ` Hannes Reinecke
2005-08-23 15:42 ` Patrick Mansfield
2005-08-23 15:53   ` Matthew Wilcox
2005-08-24  0:13   ` Luben Tuikov
2005-08-25 19:32     ` Stefan Richter
2005-08-25 20:06       ` Jeff Garzik
2005-08-26 16:43         ` Luben Tuikov
2005-08-26 17:22           ` James Bottomley [this message]
2005-08-26 18:16             ` Luben Tuikov
2005-08-26 18:48               ` Jeff Garzik
2005-08-26 19:37                 ` Luben Tuikov
2005-08-27  1:39                   ` Jeff Garzik
2005-08-27  7:11                     ` Stefan Richter
2005-08-28 22:13                     ` Luben Tuikov
  -- strict thread matches above, loose matches on Subject: below --
2005-08-23 18:25 James.Smart
2005-08-23 16:16 James.Smart
2005-08-23 17:28 ` Stefan Richter
2005-08-24  0:02   ` Luben Tuikov
2005-08-24  9:12     ` Christoph Hellwig
2005-08-26 15:47       ` Luben Tuikov
2005-08-26 19:24         ` Jeff Garzik
2005-08-26 19:44           ` Luben Tuikov
2005-08-27  1:53             ` Jeff Garzik
2005-08-27  7:35               ` Stefan Richter
2005-08-28 22:27               ` Luben Tuikov
2005-08-29  5:16               ` Stefan Richter
2005-08-29 17:11           ` Christoph Hellwig
2005-08-29 17:20             ` Luben Tuikov
2005-08-29 17:25               ` Christoph Hellwig
2005-08-29 17:16         ` Christoph Hellwig
2005-08-29 17:31           ` Luben Tuikov
2005-08-29 18:34             ` Luben Tuikov
2005-08-29 18:09           ` James Bottomley
2005-08-23 17:57 ` Patrick Mansfield
2005-08-22 23:08 Moore, Eric Dean
2005-08-24  8:59 ` Christoph Hellwig
2005-08-18 18:48 James.Smart
2005-08-18 19:04 ` Jeff Garzik
2005-08-19 14:06   ` Christoph Hellwig
2005-08-19 17:51     ` Luben Tuikov
2005-08-19 17:54       ` Christoph Hellwig
2005-08-19 17:56         ` Luben Tuikov
2005-08-19 17:59           ` Christoph Hellwig
2005-08-19 18:07             ` Luben Tuikov
2005-08-19 19:59               ` James Bottomley
2005-08-19 20:32                 ` Luben Tuikov
2005-08-19 20:54                   ` Jeff Garzik
2005-08-20  9:18                   ` Christoph Hellwig
2005-08-20 17:34                     ` Luben Tuikov
2005-08-21  6:41                       ` Arjan van de Ven
2005-08-21 17:07                       ` Christoph Hellwig
2005-08-19 19:08             ` Luben Tuikov
2005-08-18 20:06 ` Luben Tuikov
2005-08-19 14:04 ` Christoph Hellwig
2005-08-18 14:43 James.Smart
2005-08-18 14:02 James.Smart
2005-08-18 17:56 ` Christoph Hellwig
2005-08-18 20:05   ` Luben Tuikov
2005-08-19 14:15     ` Christoph Hellwig
2005-08-18 11:57 James.Smart
2005-08-15 13:55 Christoph Hellwig
2005-08-15 14:19 ` Luben Tuikov
2005-08-15 14:35 ` Arjan van de Ven
2005-08-15 15:04   ` Luben Tuikov
2005-08-15 15:13 ` Luben Tuikov
2005-08-15 15:21   ` Christoph Hellwig
2005-08-15 15:33     ` Luben Tuikov

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=1125076960.5079.61.camel@mulgrave \
    --to=jejb@steeleye.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=luben_tuikov@adaptec.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).