Porting SCSI code from Linux

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Hello

I am trying to port some Linux SCSI code. It uses ioctl SG_IO, which is
the equivalent of NetBSD ioctl SCIOCCOMMAND

The question is about status and error codes. On NetBSD, we have the
following returned:
- the return value from ioctl and associated errno
- struct scsireq -> retsts  "the return status for the command"
- struct scsireq -> status "scsi status was from the adapter"
- struct scsireq -> error "error bits"

retsts takes the values: SCCMD_OK SCCMD_TIMEOUT SCCMD_BUSY 
SCCMD_SENSE SCCMD_UNKNOWN

If I read the sources correctly, status takes the values: SCSI_OK
SCSI_CHECK SCSI_BUSY SCSI_INTERM SCSI_RESV_CONFLICT 
SCSI_TERMINATED SCSI _QUEUE_FULL SCSI_ACA_ACTIVE

And my best guess for error is the following values: XS_NOERROR 
XS_SENSE XS_SHORTSENSE XS_DRIVER_STUFFUP 
XS_RESOURCE_SHORTAGE XS_SELTIMEOUT 
XS_TIMEOUT XS_BUSY XS_RESET XS_REQUEUE

Is that correct? Now I try to map that to the Linux SG_IO ioctl return
values:

- the return value from ioctl and associated errno
- sg_io_hdr_t -> host_status
- sg_io_hdr_t -> driver status & 0x0f "driver status"
- sg_io_hdr_t -> driver status & 0xf0 "driver suggest"

The values are:

host_status: HOST_NO_CONNECT HOST_BUS_BUSY HOST_TIME_OUT 
HOST_BAD_TARGET HOST_ABORT HOST_PARITY HOST_ERROR 
HOST_RESET HOST_BAD_INTR HOST_PASSTHROUGH HOST_SOFT_ERROR 
HOST_IMM_RETRY HOST_REQUEUE HOST_TRANS_DISR HOST_TRANS_FAIL 
HOST_TARGET_FAIL HOST_NEXUS_FAIL

driver status & 0x0f: DRIVER_OK DRIVER_BUSY DRIVER_TIMEOUT
DRIVER_SENSE DRIVER_SOFT DRIVER_MEDIA DRIVER_ERROR 
DRIVER_INVALID DRIVER_HARD

driver status & 0xf0: NO_SUGGESTION SUGGEST_RETRY  SUGGEST_SENSE
SUGGEST_ABORT SUGGEST_REMAP SUGGEST_DIE

That does not map nicely. The Linux userrland code uses the return
values to choose between success, reporting error, retrying operation,
looking at sense. 

On NetBSD, things seems to be simplier:
- success: only when scsireq's retsts is SCCMD_OK, or SCCMD_SENSE with
sense data considered as success
- retying operation: If I read NetBSD scsipi kernel code correctly,
drivers report XS_REQUEUE when an operation needs to be retried, but
scsipi takes care of it, hence userland should not bother about it.
- looking at sense: it seems looking at scsireq's retsts's being
SCCMD_SENSE is enough to decide to do this

Is that correct?


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost