Marc SCHAEFER wrote:
>
> The question of the differences between /dev/sg write()/read() interface
> and SCSI_IOCTL_SEND_COMMAND was raised in the amanda-users mailing-list.
>
> I answered with the following. Any comments ? I will do a summary
> to the amanda-users mailing-list.
>
> From: Marc SCHAEFER <[EMAIL PROTECTED]>
> Newsgroups: alphanet.ml.amanda.users
> Subject: Re: Tape changer interface?
> Date: 9 Apr 2000 12:10:56 +0200
> Message-ID: <8cpkvg$7m8$[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]> <8c1e6l$lp5$[EMAIL PROTECTED]>
><8c70o3$m35$[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
> Sven Rudolph <[EMAIL PROTECTED]> wrote:
> > > - scsi-generic interface (#define LINUX_CHG) for 2.0.x
> > >
> > > - ioctl() interface (#undef LINUX_CHG) for 2.2.x
>
> > What's the difference between the last two interfaces, and what are
> > the advantages/disadvantages of these interfaces?
>
> The LINUX_CHG one uses the generic interface (/dev/sg), but it seems
> it only works in 2.0.x (sg was changed, theoretically in a
> backwards-compatible way in 2.2.x ...)
There was a large change in the implementation of the sg device
from and including 2.2.6 (just after the RH6.0 snapshot). There
were smaller changes before that (e.g. SG_SET_TRANSFORM was
introduced into sg for ide-scsi before 2.2.6 but was not in 2.0.37).
I would be interested in finding out why there was a need to
change from the sg interface to the SCSI_IOCTL_SEND_COMMAND
ioctl().
> The other one, which seems to work nicely in 2.2.x uses
>
> ioctl(DeviceFD, SCSI_IOCTL_SEND_COMMAND, Command);
>
> which seems available only in Linux 2.2.x (drivers/scsi/scsi_ioctl.c),
> although I also see it implemented in scsi_ioctl.c of 2.0.38 ...
... and 2.0.37 .
[Snipped description that uses C's declarative syntax to describe
the 3rd argument to that ioctl(). It is both convoluted and
insufficient.]
Following is the description of that ioctl() in 2.3.99 which
is accurate for earlier versions.
* This interface is depreciated - users should use the scsi generic (sg)
* interface instead, as this is a more flexible approach to performing
* generic SCSI commands on a device.
*
* The structure that we are passed should look like:
*
* struct sdata {
* unsigned int inlen; [i] Length of data to be written to device
* unsigned int outlen; [i] Length of data to be read from device
* unsigned char cmd[x]; [i] SCSI command (6 <= x <= 12).
* [o] Data read from device starts here.
* [o] On error, sense buffer starts here.
* unsigned char wdata[y]; [i] Data written to device starts here.
* };
* Notes:
* - The SCSI command length is determined by examining the 1st byte
* of the given command. There is no way to override this.
* - Data transfers are limited to PAGE_SIZE (4K on i386, 8K on alpha).
* - The length (x + y) must be at least OMAX_SB_LEN bytes long to
* accomodate the sense buffer when an error occurs.
* The sense buffer is truncated to OMAX_SB_LEN (16) bytes so that
* old code will not be surprised.
* - If a Unix error occurs (e.g. ENOMEM) then the user will receive
* a negative return and the Unix error code in 'errno'.
* If the SCSI command succeeds then 0 is returned.
* Positive numbers returned are the compacted SCSI error codes (4
* bytes in one int) where the lowest byte is the SCSI status.
* See the drivers/scsi/scsi.h file for more information on this.
> It seems to also use the generic device opening, at least, for
> non already recognized devices (presumably you can use this ioctl()
> either on /dev/sgX or /dev/sdaX if your target is a disk).
Since the SCSI_IOCTL_SEND_COMMAND ioctl() is implemented in the
SCSI mid level code than it is available to all file descriptors
that refer to scsi devices (i.e. sd, sr, st or sg).
To use the sg interface you need to open the appropriate sg device.
All sd, sr and st devices map to a sg device (as long as the 8
bit minor number range of sg isn't exceeded). I have written a
utility called "sg_map" that shows this mapping. This utility
is based on the use of the SCSI_IOCTL_GET_IDLUN ioctl() which
is also supplied by the mid level.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
