libata, SCSI and storage drivers

libata, SCSI and storage drivers

[Jeff Garzik]

Jens Axboe wrote:
> On Tue, May 24 2005, Jeff Garzik wrote:
> 
>>Jens Axboe wrote:
>>
>>>On Tue, May 24 2005, Jeff Garzik wrote:
>>>
>>>>I can describe how this will look when libata is divorced from SCSI, if 
>>>>you would like, too...
>>>
>>>I was beginning to dispair you had given up that plan...
>>
>>hehe, nope.  I promised Linus, and I plan to keep my promise :)
> 
> 
> You promised me, too :)
> 
> 
>>I know how to do it.  Internally things have been kept as separate as 
>>possible from the SCSI layer.
> 
> 
> We should start a list of items that could potentially be moved to the
> block layer that libata currently uses.


Here are the two broad categories of things that immediately come to mind.


1.  Hardware in pre-production right now can do SAS or SATA on the same 
card.  So, real soon, a driver will need to do both SCSI and ATA 
depending on runtime conditions.

The SCSI transport class is a very nice way to connect low-level drivers 
and the class drivers (disk/cdrom/tape/...).  It works well with the 
device model, and is modular in just the right location.

I would like to develop ATA transport class(es).  In order to work well 
with SATA/SAS hardware, there will need to be at least one.

And as I hoped you have guessed.....  the ATA transport class should be 
a child of the block layer, not the SCSI layer.


2.  driver API.  Linux SCSI layer provides several services which are 
generalized to any "packet transport":
* mapping of devices to protocol buses (domain topology, etc.)
* command queueing
* error handling

For hardware like ATA or I2O, this "send-command" type of API is the 
most natural way to implement a low-level driver, particularly if the 
core code provides all the necessary queueing/mapping/EH services as well.

This infrastructure is -not- specific to SCSI at all.  And it is this 
infrastructure that allowed me to bring up libata so rapidly.

	Jeff

Re: libata, SCSI and storage drivers

[Douglas Gilbert]

Jeff Garzik wrote:
> Jens Axboe wrote:
> 
>> On Tue, May 24 2005, Jeff Garzik wrote:
>>
>>> Jens Axboe wrote:
>>>
>>>> On Tue, May 24 2005, Jeff Garzik wrote:
>>>>
>>>>> I can describe how this will look when libata is divorced from 
>>>>> SCSI, if you would like, too...
>>>>
>>>>
>>>> I was beginning to dispair you had given up that plan...
>>>
>>>
>>> hehe, nope.  I promised Linus, and I plan to keep my promise :)
>>
>>
>>
>> You promised me, too :)
>>
>>
>>> I know how to do it.  Internally things have been kept as separate as 
>>> possible from the SCSI layer.
>>
>>
>>
>> We should start a list of items that could potentially be moved to the
>> block layer that libata currently uses.
> 
> 
> 
> Here are the two broad categories of things that immediately come to mind.
> 
> 
> 1.  Hardware in pre-production right now can do SAS or SATA on the same 
> card.  So, real soon, a driver will need to do both SCSI and ATA 
> depending on runtime conditions.
> 
> The SCSI transport class is a very nice way to connect low-level drivers 
> and the class drivers (disk/cdrom/tape/...).  It works well with the 
> device model, and is modular in just the right location.
> 
> I would like to develop ATA transport class(es).  In order to work well 
> with SATA/SAS hardware, there will need to be at least one.
> 
> And as I hoped you have guessed.....  the ATA transport class should be 
> a child of the block layer, not the SCSI layer.

Jeff,
Yes, the SAS HBAs that I'm aware of can connect to
SATA I/II disks "directly" on their phys.

So here are two scenarios for connecting SATA disks:

a)
  SAS HBA < -------------------------> SATA disk

b)
  SAS HBA <------>SAS_expander<------> SATA disk

In a) the interconnect is SATA. Still it is hard
to believe that the SAS HBA LLD would belong to
anything other than the SCSI subsystem (since
SAS HBAs come with 4 or 8 phys, others of which could
be in scenario b) and/or connected to SAS disks).
Hence the initiator_ports/phys/target_ports on and
seen by that SAS HBA should (also) have SAS transport
classes.

When a SAS HBA phy is not connected to anything is it
a member of a SAS transport class or a ATA transport
class (or both)?

In scenario b) the left interconnect is SAS and the
right interconnect is SATA. The SAS_expander contains
the STP<->SATA bridging function (and, for sake of
argument, no SCSI-ATA Translation (SAT) layer).
Would scenario b) also have a ATA transport
class? I'll assume it does. To be discovered it also
needs a SAS transport class. Larger enclosures are
likely to be amplifications of scenario b). The presence
of the SATA disk in scenario b) will be discovered via
the SAS SMP (i.e. talking to the SAS_expander) or via
the SES protocol (i.e. a SCSI Enclosure Services target
running near the SAS_expander). Either way if there are
a lot of SATA disks then they are likely to be held
in their initialization sequence to stop them spinning
up all at once. SAS transport intervention may be
required (staggered timers are another possibility).

Now I may be wrong but I think that one of the SAS HBAs
that I have read about that looks (externally) like
scenario a) but is actually scenario b). In other words
the SAS_expander is silicon on the HBA and it is not
controlled via the PCI bus, but rather by SMP.

This suggests to me we would need an ordered sequence of
transport classes. I really wonder about trying to model
this level of complexity in sysfs, plus the nightmare of
keeping state data of (topologically) distant nodes up
to date. At some point one needs to supply a management
pass through and hand the problem over to the user
space. The question is, at what point.


There are already FCP enclosures filled with SATA disks
on the market so this problem in not unique to SAS.
However they have (I presume) a SAT layer in their
FC enclosures so the OS thinks it is taking to SCSI
disks.

Doug Gilbert

RE: libata, SCSI and storage drivers

[James.Smart]

FYI -  There is currently a standards proposal in T11 for the
following scenario:

  c) FC HBA  <--------> FC fabric/loop <------>  SATA disk

In this case, the SAT layer could be in the FC HBA firmware or
in the FC driver (or whatever linux transport exists).  A demo for
this scenario was shown recently at SNW.

Also - I expect to see more and more implementations with the
SAS Expander tightly integrated to the SAS HBA/phys.

-- james s


> Jeff,
> Yes, the SAS HBAs that I'm aware of can connect to
> SATA I/II disks "directly" on their phys.
> 
> So here are two scenarios for connecting SATA disks:
> 
> a)
>   SAS HBA < -------------------------> SATA disk
> 
> b)
>   SAS HBA <------>SAS_expander<------> SATA disk
> 
> In a) the interconnect is SATA. Still it is hard
> to believe that the SAS HBA LLD would belong to
> anything other than the SCSI subsystem (since
> SAS HBAs come with 4 or 8 phys, others of which could
> be in scenario b) and/or connected to SAS disks).
> Hence the initiator_ports/phys/target_ports on and
> seen by that SAS HBA should (also) have SAS transport
> classes.
> 
> When a SAS HBA phy is not connected to anything is it
> a member of a SAS transport class or a ATA transport
> class (or both)?
> 
> In scenario b) the left interconnect is SAS and the
> right interconnect is SATA. The SAS_expander contains
> the STP<->SATA bridging function (and, for sake of
> argument, no SCSI-ATA Translation (SAT) layer).
> Would scenario b) also have a ATA transport
> class? I'll assume it does. To be discovered it also
> needs a SAS transport class. Larger enclosures are
> likely to be amplifications of scenario b). The presence
> of the SATA disk in scenario b) will be discovered via
> the SAS SMP (i.e. talking to the SAS_expander) or via
> the SES protocol (i.e. a SCSI Enclosure Services target
> running near the SAS_expander). Either way if there are
> a lot of SATA disks then they are likely to be held
> in their initialization sequence to stop them spinning
> up all at once. SAS transport intervention may be
> required (staggered timers are another possibility).
> 
> Now I may be wrong but I think that one of the SAS HBAs
> that I have read about that looks (externally) like
> scenario a) but is actually scenario b). In other words
> the SAS_expander is silicon on the HBA and it is not
> controlled via the PCI bus, but rather by SMP.
> 
> This suggests to me we would need an ordered sequence of
> transport classes. I really wonder about trying to model
> this level of complexity in sysfs, plus the nightmare of
> keeping state data of (topologically) distant nodes up
> to date. At some point one needs to supply a management
> pass through and hand the problem over to the user
> space. The question is, at what point.
> 
> 
> There are already FCP enclosures filled with SATA disks
> on the market so this problem in not unique to SAS.
> However they have (I presume) a SAT layer in their
> FC enclosures so the OS thinks it is taking to SCSI
> disks.
> 
> Doug Gilbert
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: libata, SCSI and storage drivers

[James.Smart]

Also, I should note that plain ATA (no SAT) is valid in this
configuration as well.

-- james s

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org]On Behalf Of Smart, James
> Sent: Friday, May 27, 2005 8:43 AM
> To: dougg@torque.net; jgarzik@pobox.com
> Cc: axboe@suse.de; James.Bottomley@SteelEye.com;
> linux-scsi@vger.kernel.org; linux-ide@vger.kernel.org
> Subject: RE: libata, SCSI and storage drivers
> 
> 
> FYI -  There is currently a standards proposal in T11 for the
> following scenario:
> 
>   c) FC HBA  <--------> FC fabric/loop <------>  SATA disk
> 
> In this case, the SAT layer could be in the FC HBA firmware or
> in the FC driver (or whatever linux transport exists).  A demo for
> this scenario was shown recently at SNW.
> 
> Also - I expect to see more and more implementations with the
> SAS Expander tightly integrated to the SAS HBA/phys.
> 
> -- james s
> 
> 
> > Jeff,
> > Yes, the SAS HBAs that I'm aware of can connect to
> > SATA I/II disks "directly" on their phys.
> > 
> > So here are two scenarios for connecting SATA disks:
> > 
> > a)
> >   SAS HBA < -------------------------> SATA disk
> > 
> > b)
> >   SAS HBA <------>SAS_expander<------> SATA disk
> > 
> > In a) the interconnect is SATA. Still it is hard
> > to believe that the SAS HBA LLD would belong to
> > anything other than the SCSI subsystem (since
> > SAS HBAs come with 4 or 8 phys, others of which could
> > be in scenario b) and/or connected to SAS disks).
> > Hence the initiator_ports/phys/target_ports on and
> > seen by that SAS HBA should (also) have SAS transport
> > classes.
> > 
> > When a SAS HBA phy is not connected to anything is it
> > a member of a SAS transport class or a ATA transport
> > class (or both)?
> > 
> > In scenario b) the left interconnect is SAS and the
> > right interconnect is SATA. The SAS_expander contains
> > the STP<->SATA bridging function (and, for sake of
> > argument, no SCSI-ATA Translation (SAT) layer).
> > Would scenario b) also have a ATA transport
> > class? I'll assume it does. To be discovered it also
> > needs a SAS transport class. Larger enclosures are
> > likely to be amplifications of scenario b). The presence
> > of the SATA disk in scenario b) will be discovered via
> > the SAS SMP (i.e. talking to the SAS_expander) or via
> > the SES protocol (i.e. a SCSI Enclosure Services target
> > running near the SAS_expander). Either way if there are
> > a lot of SATA disks then they are likely to be held
> > in their initialization sequence to stop them spinning
> > up all at once. SAS transport intervention may be
> > required (staggered timers are another possibility).
> > 
> > Now I may be wrong but I think that one of the SAS HBAs
> > that I have read about that looks (externally) like
> > scenario a) but is actually scenario b). In other words
> > the SAS_expander is silicon on the HBA and it is not
> > controlled via the PCI bus, but rather by SMP.
> > 
> > This suggests to me we would need an ordered sequence of
> > transport classes. I really wonder about trying to model
> > this level of complexity in sysfs, plus the nightmare of
> > keeping state data of (topologically) distant nodes up
> > to date. At some point one needs to supply a management
> > pass through and hand the problem over to the user
> > space. The question is, at what point.
> > 
> > 
> > There are already FCP enclosures filled with SATA disks
> > on the market so this problem in not unique to SAS.
> > However they have (I presume) a SAT layer in their
> > FC enclosures so the OS thinks it is taking to SCSI
> > disks.
> > 
> > Doug Gilbert
> > 
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> > linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: libata, SCSI and storage drivers

[Luben Tuikov]

On 05/27/05 02:45, Douglas Gilbert wrote:
> In a) the interconnect is SATA. Still it is hard
> to believe that the SAS HBA LLD would belong to
> anything other than the SCSI subsystem (since
> SAS HBAs come with 4 or 8 phys, others of which could
> be in scenario b) and/or connected to SAS disks).
> Hence the initiator_ports/phys/target_ports on and
> seen by that SAS HBA should (also) have SAS transport
> classes.

It should register with the SAS transport class, where
the SAS discover "function" is.  The Discover function
would find out what is out on the domain and "register"
it with the proper "transport" (a more correct way to
put it there is).

For SSP devices that would be a "scsi disk", for
SATA devices that would be a "libata disk" or something
like this.  The LLDD would either get a CDB for SSP,
or taskfile for STP, and pass it along to the hardware.
 
> When a SAS HBA phy is not connected to anything is it
> a member of a SAS transport class or a ATA transport
> class (or both)?

Quite possibly both: SAS transport class, since it is
a super class in meaning that the Discover function
is in there.
 
> In scenario b) the left interconnect is SAS and the
> right interconnect is SATA. The SAS_expander contains
> the STP<->SATA bridging function (and, for sake of
> argument, no SCSI-ATA Translation (SAT) layer).
> Would scenario b) also have a ATA transport
> class? I'll assume it does. To be discovered it also

Yes it would.  As far as the class is concerned it
is a SATA device -- how you get to it (direct or through
an expander) is the LLDD/firmware/Host Adapter concern.

> needs a SAS transport class. Larger enclosures are
> likely to be amplifications of scenario b). The presence
> of the SATA disk in scenario b) will be discovered via
> the SAS SMP (i.e. talking to the SAS_expander) or via
> the SES protocol (i.e. a SCSI Enclosure Services target
> running near the SAS_expander). Either way if there are
> a lot of SATA disks then they are likely to be held
> in their initialization sequence to stop them spinning
> up all at once. SAS transport intervention may be
> required (staggered timers are another possibility).

Yes, spinup-hold states would be managed by the Discover
function, or by the FW on the expander/ses device.

BTW, very nice to mention SES devices.  We'll have to
bring that up more as they'd be very much en vogue
with expanders.

> Now I may be wrong but I think that one of the SAS HBAs
> that I have read about that looks (externally) like
> scenario a) but is actually scenario b). In other words
> the SAS_expander is silicon on the HBA and it is not
> controlled via the PCI bus, but rather by SMP.

I know of such a SAS HA (Host Adapter), and from what it
seems the role of the expander-on-chip is to simulate
a larger number of phys than actually/physically supported
by the HA.  By design, this should be transparent to the
Discover function, and if it is not, I believe the Discover
fn. would do the right thing (i.e. treat is as an expander).

> This suggests to me we would need an ordered sequence of
> transport classes. I really wonder about trying to model
> this level of complexity in sysfs, plus the nightmare of
> keeping state data of (topologically) distant nodes up
> to date. At some point one needs to supply a management

When a SSP talking device is found it is registered
as a "scsi device".  When a STP talking device is
discovered (directly attached or elsewhere) it would
be registered as a "libata device".

> pass through and hand the problem over to the user
> space. The question is, at what point.

I'm not 100% sure about user space.  The Discover function
is pretty straightforward, and simple.  Plus the root/bootable
device could be a SATA device on an expander or even deeper
in the domain.

Thanks,
	Luben

RE: libata, SCSI and storage drivers

[James.Smart]

Folks,

This discussion brings up some latent questions...

The transport can be a subsystem on it's own and is perhaps independent
of SCSI altogether. In this case, SCSI just happens to be a personality
of something on the transport. This is at odds with the current design
in which the transport is something under SCSI and inherently bound to
the SCSI "host".

I understand how we got to where we are, but shouldn't we consider making
some transports independent subsystems ? If the only protocol that
can be run on the transport is SCSI (ex: SPI), then the transport can be
under SCSI. However, if the transport can support multiple protocols (FC
can support SCSI, IP, (or ATA)), shouldn't it be structured more like an io
bus like pci ? 

It does mess up the device tree heirarchy. In general, you want the
device tree to continue along the transport specific elements until it finds
remote endpoints (things your going to use), at which point the protocol
specific elements can kick in. For example (using FC):
 /sys/devices/<pci>/fcport5/rport-5:3/target10:0:0/10:0:0:0  - the SCSI lun

What this leaves out is : where is the scsi host device ? It doesn't make
sense to insert it in-between the transport elements. It likely just becomes
a leaf entity. Continuing the example:
 /sys/devices/<pci>/fcport5/host10  - scsi host interface
 /sys/devices/<pci>/fcport5/eth3    - network interface

Food for thought...   Is this out in left field ?

-- james s


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org]On Behalf Of Luben Tuikov
> Sent: Friday, May 27, 2005 10:42 AM
> To: dougg@torque.net
> Cc: Jeff Garzik; Jens Axboe; James Bottomley; SCSI Mailing List;
> linux-ide@vger.kernel.org
> Subject: Re: libata, SCSI and storage drivers
> 
> 
> On 05/27/05 02:45, Douglas Gilbert wrote:
> > In a) the interconnect is SATA. Still it is hard
> > to believe that the SAS HBA LLD would belong to
> > anything other than the SCSI subsystem (since
> > SAS HBAs come with 4 or 8 phys, others of which could
> > be in scenario b) and/or connected to SAS disks).
> > Hence the initiator_ports/phys/target_ports on and
> > seen by that SAS HBA should (also) have SAS transport
> > classes.
> 
> It should register with the SAS transport class, where
> the SAS discover "function" is.  The Discover function
> would find out what is out on the domain and "register"
> it with the proper "transport" (a more correct way to
> put it there is).
> 
> For SSP devices that would be a "scsi disk", for
> SATA devices that would be a "libata disk" or something
> like this.  The LLDD would either get a CDB for SSP,
> or taskfile for STP, and pass it along to the hardware.
>  
> > When a SAS HBA phy is not connected to anything is it
> > a member of a SAS transport class or a ATA transport
> > class (or both)?
> 
> Quite possibly both: SAS transport class, since it is
> a super class in meaning that the Discover function
> is in there.
>  
> > In scenario b) the left interconnect is SAS and the
> > right interconnect is SATA. The SAS_expander contains
> > the STP<->SATA bridging function (and, for sake of
> > argument, no SCSI-ATA Translation (SAT) layer).
> > Would scenario b) also have a ATA transport
> > class? I'll assume it does. To be discovered it also
> 
> Yes it would.  As far as the class is concerned it
> is a SATA device -- how you get to it (direct or through
> an expander) is the LLDD/firmware/Host Adapter concern.
> 
> > needs a SAS transport class. Larger enclosures are
> > likely to be amplifications of scenario b). The presence
> > of the SATA disk in scenario b) will be discovered via
> > the SAS SMP (i.e. talking to the SAS_expander) or via
> > the SES protocol (i.e. a SCSI Enclosure Services target
> > running near the SAS_expander). Either way if there are
> > a lot of SATA disks then they are likely to be held
> > in their initialization sequence to stop them spinning
> > up all at once. SAS transport intervention may be
> > required (staggered timers are another possibility).
> 
> Yes, spinup-hold states would be managed by the Discover
> function, or by the FW on the expander/ses device.
> 
> BTW, very nice to mention SES devices.  We'll have to
> bring that up more as they'd be very much en vogue
> with expanders.
> 
> > Now I may be wrong but I think that one of the SAS HBAs
> > that I have read about that looks (externally) like
> > scenario a) but is actually scenario b). In other words
> > the SAS_expander is silicon on the HBA and it is not
> > controlled via the PCI bus, but rather by SMP.
> 
> I know of such a SAS HA (Host Adapter), and from what it
> seems the role of the expander-on-chip is to simulate
> a larger number of phys than actually/physically supported
> by the HA.  By design, this should be transparent to the
> Discover function, and if it is not, I believe the Discover
> fn. would do the right thing (i.e. treat is as an expander).
> 
> > This suggests to me we would need an ordered sequence of
> > transport classes. I really wonder about trying to model
> > this level of complexity in sysfs, plus the nightmare of
> > keeping state data of (topologically) distant nodes up
> > to date. At some point one needs to supply a management
> 
> When a SSP talking device is found it is registered
> as a "scsi device".  When a STP talking device is
> discovered (directly attached or elsewhere) it would
> be registered as a "libata device".
> 
> > pass through and hand the problem over to the user
> > space. The question is, at what point.
> 
> I'm not 100% sure about user space.  The Discover function
> is pretty straightforward, and simple.  Plus the root/bootable
> device could be a SATA device on an expander or even deeper
> in the domain.
> 
> Thanks,
> 	Luben
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: libata, SCSI and storage drivers

[Jeff Garzik]

James.Smart@Emulex.Com wrote:
> Folks,
> 
> This discussion brings up some latent questions...
> 
> The transport can be a subsystem on it's own and is perhaps independent
> of SCSI altogether. In this case, SCSI just happens to be a personality
> of something on the transport. This is at odds with the current design
> in which the transport is something under SCSI and inherently bound to
> the SCSI "host".

Yes.  This is something I really want to change, for libata.


> I understand how we got to where we are, but shouldn't we consider making
> some transports independent subsystems ? If the only protocol that
> can be run on the transport is SCSI (ex: SPI), then the transport can be
> under SCSI. However, if the transport can support multiple protocols (FC
> can support SCSI, IP, (or ATA)), shouldn't it be structured more like an io
> bus like pci ? 

Unfortunately this is an open-ended question that Linux is rather poor 
at answering, since the answer could range from "no" to "show me the 
code" to "you're an absolute visionary!"  :)

My own opinion:

I consciously avoid thinking too much in that direction.  Linux 
development is a lot like a biological process.  The evolution of the 
kernel code over time will give us the best answer.

Perhaps we will merge request_queue and network stack systems into a 
single "packet transport" system.  Perhaps net stack and request_queue 
systems will stay separate, and request_queue will evolve into a 
generalized system for RPC message transport.

With the device model, both IDE [as of yesterday] and SCSI -already- 
export bus topology in a standardized manner, just like PCI.

	Jeff

RE: libata, SCSI and storage drivers

[James Bottomley]

On Fri, 2005-05-27 at 13:45 -0400, James.Smart@Emulex.Com wrote:
> The transport can be a subsystem on it's own and is perhaps independent
> of SCSI altogether. In this case, SCSI just happens to be a personality
> of something on the transport. This is at odds with the current design
> in which the transport is something under SCSI and inherently bound to
> the SCSI "host".

Actually, no that's no longer true.  Initially I did it this way, but
now the SCSI transport classes are build on top of the generic transport
classes (and these are independent of SCSI).  I anticipate that soon
we'll get a PHY transport class that will attach both to SAS and SATA
devices (and won't care which subsystem they're under).

> I understand how we got to where we are, but shouldn't we consider making
> some transports independent subsystems ? If the only protocol that
> can be run on the transport is SCSI (ex: SPI), then the transport can be
> under SCSI. However, if the transport can support multiple protocols (FC
> can support SCSI, IP, (or ATA)), shouldn't it be structured more like an io
> bus like pci ? 
> 
> It does mess up the device tree heirarchy. In general, you want the
> device tree to continue along the transport specific elements until it finds
> remote endpoints (things your going to use), at which point the protocol
> specific elements can kick in. For example (using FC):
>  /sys/devices/<pci>/fcport5/rport-5:3/target10:0:0/10:0:0:0  - the SCSI lun
> 
> What this leaves out is : where is the scsi host device ? It doesn't make
> sense to insert it in-between the transport elements. It likely just becomes
> a leaf entity. Continuing the example:
>  /sys/devices/<pci>/fcport5/host10  - scsi host interface
>  /sys/devices/<pci>/fcport5/eth3    - network interface
> 
> Food for thought...   Is this out in left field ?

Well, that's why it's a class.  All the devices appear under 

/class/<transport class name>

and these devices are simply the names of the actual generic devices, so
there's no reason target0:3:0 can't co-exist happily with ata3:0 or
something here.  The idea being (I think) that the class infrastructure
actually flattens the tree.  So there's always a device link that points
into the true device tree, but all the class properties are available in
flattened form.

James