[7197] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

Re: Fixing SCSI Layer

daemon@ATHENA.MIT.EDU (Tony Chung)
Thu Sep 9 18:29:12 1999

Date:   Thu, 09 Sep 1999 14:01:21 -0700
From:   Tony Chung <chungto@ampex.com>
To:     linux-scsi@vger.rutgers.edu


--------------F811966F503EA0C7E136A4C2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



>
> 1 - Add a 'direction' field to the scsi command structure that can be
>     filled with the following values:
>       DIR_INPUT, DIR_OUTPUT, DIR_NONE and DIR_UNKNOWN=0
>       Set this field to DIR_UNKNOWN=0 by default.
>

From Digital Unix  /usr/include/io/cam.h:

/* Defines for the CAM flags field in the CCB header. */

#define CAM_DIR_RESV       0x00000000   /* Data direction (00: reserved) */
#define CAM_DIR_IN         0x00000040   /* Data direction (01: DATA IN) */
#define CAM_DIR_OUT        0x00000080   /* Data direction (10: DATA OUT) */
#define CAM_DIR_NONE       0x000000C0   /* Data direction (11: no data) */

While UDI scsi spec has:
#define UDI_SCSI_DATA_IN   (1U<<0)
#define UDI_SCSI_DATA_OUT (1U<<1)

Basically, it can't be UNKNOWN because the Peripheral Driver must specify the
buffer address and total transfer size. Any  inconsistencies should return error

or let the host adaptor card simply return data overrun or data underrun.


I found CAM_DIR_NONE is potential hazard because
if some one specify CAM_DIR_NONE, another person
may mistakenly check for:
        If (flags & CAM_DIR_OUT) ...../* condition true and do something wrong
*/


I believe Linux should go for a standard (either UDI or CAM) and leave the
current interface alone (assuming things are still working).
The biggest problem is which standard is better and the effort and time to
accomplish it.

--
=============================
Tony Chung



--------------F811966F503EA0C7E136A4C2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>1 - Add a 'direction' field to the scsi command structure that can
be
<br>&nbsp;&nbsp;&nbsp; filled with the following values:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIR_INPUT, DIR_OUTPUT, DIR_NONE and
DIR_UNKNOWN=0
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set this field to DIR_UNKNOWN=0 by default.
<br>&nbsp;</blockquote>
From Digital Unix&nbsp; /usr/include/io/cam.h:
<pre>/* Defines for the CAM flags field in the CCB header. */

#define CAM_DIR_RESV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00000000&nbsp;&nbsp; /* Data direction (00: reserved) */
#define CAM_DIR_IN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00000040&nbsp;&nbsp; /* Data direction (01: DATA IN) */
#define CAM_DIR_OUT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x00000080&nbsp;&nbsp; /* Data direction (10: DATA OUT) */
#define CAM_DIR_NONE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x000000C0&nbsp;&nbsp; /* Data direction (11: no data) */
</pre>
While UDI scsi spec has:
<br>#define UDI_SCSI_DATA_IN&nbsp;&nbsp; (1U&lt;&lt;0)
<br>#define UDI_SCSI_DATA_OUT (1U&lt;&lt;1)
<p>Basically, it can't be UNKNOWN because the Peripheral Driver must specify
the
<br>buffer address and total transfer size. Any&nbsp; inconsistencies should
return error
<br>or let the host adaptor card simply return data overrun or data underrun.
<br>&nbsp;
<p>I found CAM_DIR_NONE is potential hazard because
<br>if some one specify CAM_DIR_NONE, another person
<br>may mistakenly check for:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If (flags &amp; CAM_DIR_OUT)
...../* condition true and do something wrong */
<br>&nbsp;
<p>I believe Linux should go for a standard (either UDI or CAM) and leave
the
<br>current interface alone (assuming things are still working).
<br>The biggest problem is which standard is better and the effort and
time to
<br>accomplish it.
<pre>--&nbsp;
=============================
Tony Chung</pre>
&nbsp;</html>

--------------F811966F503EA0C7E136A4C2--


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu

home help back first fref pref prev next nref lref last post