Re: [PATCH] SCSI Core patches

[Luben Tuikov <luben@splentec.com>]

Patrick Mansfield wrote:
 >
> This is _not_ just for multi-path. The current scsi code does not properly
> size the target and lun based on the transport. For SPI the target and lun
> need only be one byte; for FCP they are 4 and 8 bytes; for iSCSI I don't
> know what. (Our current four byte host-ordered lun does not match anything
> in any SCSI spec.)

I brought this up last year sometime, either privately or here (search
the archives if anyone is interested) and the idea of using a 64-bit LUN
was shot down as in ``we don't need so many bits''.

The problem is that due to its hierarchical structure all 64 bits are
used. If SPI wants to use 5 bits, let it use 5 bits, if iSCSI wants
to use 64, we've got this covered too.

But it would not be interpreted by SCSI Core, i.e. SCSI Core will simply
copy around the LUN.

BTW, a LUN is a well defined object, cf. SAM-3, 4.9.

> Having a scsi_nexus or such that is host adapter specific (something like
> Mike A. posted about) possibly with common transport code (for FCP, SPI,
> and iSCSI) would be useful, and would make it easier to add multi-pathing
> or support for future transports. The scsi_device current_tag, sdtr, wdtr,
> and ppr would be moved to a scsi_nexus since they are SPI specific.

SCSI Core should know as little as possible about the transport, IMHO.

Also I'd get rid of ``current_tag'', and leave only information as to
what kind of task management the device supports (BQue and CmdQue bits
in INQUIRY data). Also see:

http://MARC.10East.com/?l=linux-scsi&m=103488799412511&w=2

-- 
Luben