Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2

[Douglas Gilbert <dougg@torque.net>]

Scott M. Ferris wrote:
<snip>
> 
> Should all drivers that currently use one host for each SCSI initiator
> device, and a channel for each initiator port on each device, be
> modified to use a host for each initiator port?
> 
> Documentation/scsi/scsi_mid_low_api.txt says that a host corresponds
> to a SCSI initiator device.  Could someone change that to say SCSI
> initiator port instead, since that seems to be the new goal?

Scott,
Yes, I can change that if we all agree. Randy Dunlap asked me some
time back to define what was meant by a "linux SCSI host" and that
was the best I could come up with at the time.


Interesting to see you mention SAS. There could be lots of fun
for the linux SCSI subsystem here:
   - addressable switching elements (called "expanders") in the
     SCSI domain ** service delivery subsystem. These are not
     SCSI devices (in the SAM sense) but are pretty close. They
     are controlled by a packetized protocol called SMP whose
     initiator end sits on a host and target end sits on an
     expander. [SMP has no concept of logical units.]
   - discovery is either dead simple (for example when a disk is
     directly connected to a HBA's phy [like SATA]) or something
     that needs a breadth first, hierarchial descent through
     expanders to end devices. The latter type of discovery is
     probably better done from the user space.
   - in SCSI, devices can have multiple ports and in SAS a port can
     be made up of multiple phys (i.e. a wide link). The SCSI
     subsystem can ignore phys and just talk about ports but
     users can see and touch phys (e.g. those SATA red cables).
     Also expander routing is done at the link level.

It would be great to see a transport class architecture that
could cope with this. Think about how a SMP target device
(i.e. an expander's control port) will be represented.
I don't think struct scsi_device is appropriate ...


** the term "bus" seems to have lost favour in SAM and been
    replaced by the term "domain".


A few related matters:

Steven Fairchild dropped a proposal for SAS storage management
called "Common Storage Management Interface for SAS" in the
t10 "New Documents and Drafts" section. The url is:
http://www.t10.org/ftp/t10/document.04/04-284r0.pdf
A linux interface and driver is proposed.

A draft standard titled "SCSI-ATA translation" (SAT) is moving
along briskly. The primary target areas for this translator are
in a SAS host above an SAS domain when some of the "SCSI" devices
are SATA disks and SCSI-(p/s)ATA bridges.

Doug Gilbert