status as in SAM2

Hello there.

Given SCpnt->result and that queuecommand() has returned with error or done() was called, how can I find out the status byte as per SAM2, given SCpnt->result?

Is it just ``status_byte(SCpnt->result)''? (macro defined in scsi.h)

TIA,

Luben

Luben,
The actual scsi status (bits as defined in SAM-2 and elsewhere) is given by the expression:
(0xff & SCpnt->result)

Traditionally linux has used a one bit shifted and masked version of this called internally the "status_byte" which is the macro you referred to:
#define status_byte(result) (((result) >> 1) & 0x1f)

It masks "vendor" bits (in SCSI 2) which were bits 0, 6 and 7. This is dangerous since SAM-2 now uses bit 6:
0x40 ----> Task Aborted
and states all bit patterns other than those in Table 22 (Status codes) [SAM-2 draft T10/1157-D revision 23] are reserved. I guess that stops vendors using bits 0 and
7. Has anyone every seen those bits used?

Perhaps it is time (in lk 2.5) to get rid of the current status_byte macro "cleverness", change it to:
#define status_byte(result) ((result) & 0xff)
and change the "offset" defines for CHECK_CONDITION and friends in include/scsi/scsi.h to their SAM-2 values. Alternatively new defines could be introduced prefixed with "SCSI_" for the standard values. The sg driver is the only scsi interface that I'm aware of that exposes the result of the status_byte() macro to the user space and it could be set up not to surprise existing applications.

Doug Gilbert

Thanks Douglas,

I looked in the low-level scsi device drivers (LLDD) and it seems to me that not all bother to set the status byte right (even more so for emulated scsi like the 3ware).

For compatibility I use something like this:

status = (uint8_t) ((status_byte(SCpnt->result) << 1) & 0xFF);

but I'd _much_ rather use the form you suggested:

status = SCpnt->result & 0xFF;

but am not sure if the position of the status byte will change within the 32 bit result.

It would even be better if the device server status byte has it's own byte variable in SCpnt, so that LLDD writers feel ``encouraged'' to set it explicitly, rather than the mid-level try and guess its value using scsi_sense_valid(), and the driver byte...

I'm all for it!

Thanks,

Luben
P.S. A new breed of SCSI HBA heavily rely
on the device server status byte being reported right,
and I'm kind of set back to see that the LLDD don't
report it always... But I guess that depends on
the underlying hardware (device server)...