I have been playing around with the SG_IO ioctl() that
recently appeared in drivers/block/scsi_ioctl.c .

First a warning: using sg's write()/read() interface is
a dangerous thing to do to anything other than an sg device
(especially a disk). The utilities in sg3_utils (and sg_utils)
took the precaution of sending a "sg" ioctl and assumed if
it worked then the file descriptor referred to a sg device.
Now _all_ block devices respond to the ioctl()s I chose :-(

IMO sg's write()/read() interface is still useful for
queuing and high speed applications. However for the
great majority of cases the SG_IO ioctl is sufficient.
It turns out that sg3_utils version 1.01 doesn't scribble
on disks (as outlined above), more by luck than good
management. Several things fail (e.g. sg_logs) that can
easily be fixed while sg_inq and sg_dd work. [sg_dd
works because it treats /dev/sda as a normal file
rather than a sg device.] I will release sg3_utils
version 1.02 shortly.

The error processing of the SG_IO ioctl() is broken as
far as I can determine. My attached patch drives output
values to 0 (their inert values) and rescues the scsi
status value from the scsi_request structure. Notice
the hack in drivers/scsi/scsi_lib.c to stop the
gratuitous clearing of req->errors. The sense buffer
is not conveyed into struct request and there seems to
be no code in scsi_lib.c to do that.

To keep the block SG_IO consistent with sg's version,
I removed the EIO errno conditions. CHECK CONDITION
does not (necessarily) indicate an error. Witness the
code fix around lk 2.4.18 to correctly handle
RECOVERED_ERROR. So a return value of zero implies
that a consistent set of values has been written
back into the sg_io_hdr instance (and the application
best check them).

The patch is against lk 2.5.50bk3

Doug Gilbert