SCSI target subsystem

[Vladislav Bolkhovitin <vst@vlnb.net>]

[-- Attachment #1: Type: text/plain, Size: 3728 bytes --]

James Bottomley wrote:
> On Fri, 2008-05-02 at 18:06 +0200, Bart Van Assche wrote:
>> James Bottomley clearly expressed in that thread that he doesn't want
>> to maintain two SCSI target frameworks. So what I propose is that SCST
>> is included in the mainline and afterwards that it is evaluated
>> whether or not it is desirable to keep other target code in the
>> mainline kernel.
> 
> That's hardly sufficient.  STGT is already in use.  Their either has to
> be a migration path or, the preferred option, take the pieces of SCST
> that are actual improvements and embed them in STGT.

Actually, between SCSI initiator and target subsystems there is almost 
*nothing* in common. This claim, at first glance, looks pretty wrong, 
because both serve SCSI, so they must have a lot common. But look deeper 
and you quickly find out that the majority of functionality as well as 
data they use are dedicated for each subsystem, not shared.

Just look at SCST/qla2x00t/(changes done in the initiator qla2xxx driver 
to support target mode, patch attached): 90% of changes is adding 
callbacks for external target add-on, the rest is support for older, 
than 2.6.17, kernels and sysfs magic. Note, no data are common between 
initiator and target parts in the meaning that they both use them.

Then look at SCST (http://scst.sf.net). It implements complete 
pass-through SCSI support and look how it interacts with initiator SCSI 
subsystem. It calls only 2 functions: FIFO version of 
scsi_execute_async() (original scsi_execute_async() provides 
unacceptable LIFO commands order) and scsi_reset_provider() for task 
management. And there is only one common variable: struct scsi_device. 
That's all! In other storage modes (FILEIO/BLOCKIO) there is nothing 
common with SCSI initiator subsystem at all.

Finally, try to find out in SCST any duplicated functionality.

Now, let's look how SCSI target/initiator integration currently done in 
the kernel. For me it looks pretty artificial. For example, if I make a 
general purpose kernel, for which 1% of users would run target mode, I 
would have to enable as module "SCSI target support" as well as SCSI 
target support for transport attributes. Now 99% of users of my kernel, 
who don't need SCSI target, but need SCSI initiator drivers, would have 
to have scsi_tgt loaded, because transport attribute drivers would 
depend on it:

# lsmod
Module                  Size  Used by
qla2xxx               130844  0
firmware_class          8064  1 qla2xxx
scsi_transport_fc      40900  1 qla2xxx
scsi_tgt               12196  1 scsi_transport_fc
brd                     6924  0
xfs                   511280  1
dm_mirror              24368  0
dm_mod                 51148  1 dm_mirror
uhci_hcd               21400  0
sg                     31784  0
e1000                 114536  0
pcspkr                  3328  0

No target functionality needed, but target mode subsystem is needed. Is 
it a good design?

I wrote all above to support my at first glance shocking conclusion that 
SCSI target subsystem is completely new subsystem of the kernel and it 
should live on its own with its own maintainer! This is the same as with 
the current interaction between SCSI and block subsystems in the kernel: 
SCSI uses block's functionality, but that doesn't mean that block and 
SCSI are the same subsystem.

Thus, how IMHO initiator and target drivers should be written:

  - All initiator drivers should live in the SCSI initiator subsystem 
(aka current SCSI subsystem) only, the same as today.

  - All target drivers should live in the SCSI target subsystem only and 
be either add-ons to initiator drivers, like, e.g., qla2x00t, or be a 
complete driver, like, e.g., iSCSI-SCST.

Vlad


[-- Attachment #2: qla2x00t.diff.gz --]
[-- Type: application/x-gzip, Size: 17294 bytes --]