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 m...@netbsd.org
