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


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to