Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

I've enclosed below the mapping of service response status from the LLP to 
the ULP for HP-UX, Solaris, SVR4 (MP-RAS) and NT. 
As you can see, all O.S SCSI stacks should have some form of 
a service response status from their LLP 
(HBA drivers, mini-port drivers, LLDs, interface drivers)
to their ULP (target drivers, class drivers, HLDs, device drivers).

In SAM-2 (Section 4.13)  terminology :

A SCSI Protocol (Parallel SCSI, SCSI-FCP, iSCSI, etc) MUST NOT 
specify the service response in the "Protocol Service Confirmation" as
this is common for all SCSI LLPs with their ULPs for each O.S. scsi stack.
(see the list below).

SCSI Protocols MUST specify the service response in the protocol specific
PDU Responses that are exchanged between target and initiator,
as this is to be defined for target-initiator communication
for each SCSI protocol.
Ex : Response Info in FCP_RSP PDU of Fibre Channel as defined in
SCSI-FCP-2.

Given the above, I would like to propose :
==========================================

o	Removal of the 3rd paragraph of Section 5.4 of the 03 rev of the
	iSCSI draft which states :
	"When a session is active whenever an initiator receives an iSCSI
	PDU with a format error......."

o	Re-introduction and specification of Response Data in the SCSI
	Response PDU along the lines of the Response Info defined for 
	FCP_RSP in FCP-2. Even a single Response byte along the lines of
	the current Respnse field in SCSI Task Management Response PDU 
	should be sufficient.

o	Specification of a more detailed Response field in the SCSI Task
	Management Response PDU that should include the following :
	1) "No such LUN" 
	   (Abort Task Set, CLear Task Set or LUN Reset is 
	    attempted on an invalid LUN.)
	2) "Logical Busy"
	   (A 2nd Task Management Command is attempted while a prior
	   conflicting task is in progress. Ex : attempting a LUN Reset
	   while a Target Reset is in progress, etc.)
	3) "Function Not Supported"
	   (To indicate no support for certain task management commands
	   like Target Reset.)

Thanks & Regards,
Santosh

==================================================================
O.S.		Service Response	Service Delivery or
					Target Failure
==================================================================
HP-UX		scb->cdb_status 	SCTL_INCOMPLETE,
					SCTL_SELECT_TIMEOUT.

Solaris		scsi_pkt->pkt_reason	CMD_INCOMPLETE,
					CMD_TRAN_ERROR,
					CMD_ABORTED,
					CMD_TIMEOUT

		scsi_pkt->pkt_statistics STAT_ABORTED
					STAT_TIMEOUT

SVR4 MP-RAS	Scsi_Op->OP_Status	(Had something similar.
					 Can't recollect off 
					 the top of my head.)

NT		srb->SrbStatus		SRB_STATUS_ABORTED,
					SRB_STATUS_ERROR,
					SRB_STATUS_TIMEOUT, and many
					more.
==================================================================



> > Except for task management that is common to all protocols I did not
> > see any other thing popping up in any SCSI driver.
> 
> ???  Are you saying that you don't see where the service response
> status code is concretely instantiated in ANY SCSI driver?
> 
> Take CAM.  The CAM status is the service response status code.  It includes
> values like:
>   request completed without error
>   request aborted by host
>   invalid request
>   target selection timeout
>   command timeout
>   data overrun
>   unexpected bus free
> 
> etc..
> 
> Solaris and IRIX are similar (don't have the code on hand).  I can't
> imagine that ANY other SCSI driver does not have this component, but I
> clearly have not seen all other SCSI drivers.
> 


-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################