Re: [PATCH 3/3] MidLayer updates - extending scsi_target support

[Douglas Gilbert <dougg@torque.net>]

James.Smart@Emulex.Com wrote:
>>the idea behind this is fine, I just don't like the interface.
>>
>>Really a target device is nothing more than a container to SCSI.  We
>>already do the transport add/remove calls for targets, I don't see we
>>need other calls duplicating this.  So, I think the 
>>implementation would
>>look a whole lot better if the fc transport class just exported an
>>interface to get the extra storage for the driver and tacked it on to
>>its allocation.  Then you can use the existing mid-layer transport
>>target triggers to do everything you want.
> 
> 
> This can certainly be transport-specific. However, I assumed the better
> solution was to make it more generic as there's nothing about this
> problem that's transport-centric. If a driver only tracks things by 
> target (not lun), it makes a whole lotta sense to allow for per-target
> data.

Targets "speak" the same transport protocol as the HBA.
This cannot necessarily be said about logical units.
Bridges are being proposed between SAS and SPI in which
U160/U320 disks on a SPI bus appear as luns on a single
SAS target (i.e. the bridge device). If the initiator
wants to speak to the disks then it uses luns (most likely
where SPI target ids appear as luns). The initiator may be
a little surprised if it queries the protocol specific mode
and log pages on those disks (as they will reveal their
native SPI transport characteristics). To query and configure
the bridge (and  perhaps check its protocol specific mode
and logs pages) well known logical unit numbers will be used.

SCSI targets seem like an important abstraction in their
own right, not just containers for lus.

Doug Gilbert