On Thu, 9 Sep 1999, Tony Chung wrote:
> > 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) */
Refer to the standard, please, rather than vendor stuff, even if the
CAM standard was based on digital Ultrix CAM.
The topic was to clean-up Linux-SCSI which is not CAM.
> While UDI scsi spec has:
> #define UDI_SCSI_DATA_IN (1U<<0)
> #define UDI_SCSI_DATA_OUT (1U<<1)
UDI is not a standard and seem to me some poor sci-fi and will never
happen in my systems.
> 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
> */
You just misread the specs. The direction is encoded on the 3 bits 0xc0.
So you must only test against these 3 bits. You may define some mask that
CAM3 seems to not talk about:
#define CAM_DIR_MASK 0xc0
if ((flags & CAM_DIR_MASK) == CAM_DIR_OUT) ../* Everything's right now */
CAM requires the data direction (or none) to be provided in the Execute
SCSI IO request CCB, but existing Linux applications donnot provide the
data direction since the current SCSI interface just does not allow this
information to be passed. We must deal with compatibility issues.
> 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.
The better one is the one that is a real standard. The other one is to be
ignored, in my opinion.
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
