On Fri, 21 Apr 2000, Douglas Gilbert wrote:
> Same logic applies to SCSI_IOCTL_SEND_COMMAND [SISC] while
> CDROM_SEND_PACKET [CSP] has a data direction flag.
> Actually the data_direction flag is worse because in the cases
> of sg_io_hdr and CSP they allow an UNKNOWN direction value.
> NONE no problem [sg_header, sg_io_hdr, SISC, CSP]
> READ no problem [sg_header, sg_io_hdr, SISC, CSP]
> WRITE no problem [sg_header, sg_io_hdr, SISC, CSP]
> UNKNOWN problem for USB? [sg_io_hdr, CSP]
> BIDIRECTIONAL assume read [sg_header**, sg_io_hdr, SISC**]
Hrm... I'm confused. You say that CSP has a data direction flag, but the
sg_io_hdr, CSP case is the one where we could wind up with UNKNOWN. This
implies (to me, at least -- please clarify if I'm wrong) that one of the
flag options for CSP is UNKNOWN.
To me, if a user-level application is using CSP to issue commands and
chooses to set the field to UNKNOWN, that's a bug in the application.
Perhaps it's not something we've enforced in the past, but I think we
should.
And yes, the UNKNOWN case is a problem for USB.
> The "assume read" is not defined in the documentation of those
> marked "**" but can be. In the case of sg_header the above table
> is what it was (up to 2.3.99-pre2) and was changed so the clear
> READ and WRITE case was changed to UNKNOWN, as was the less
> obvious BIDIRECTIONAL case. I believe this was a mistake.
Well, I don't know enough to know if your logic on determining direction
is correct, but if it is, then we should probably use it to set the
sc_data_direction field.
But, the question still remains about the truly UNKNOWN case. For this, a
sg-level table may be the only way to go.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
Stef, you just got beaten by a ball of DIRT.
-- Greg
User Friendly, 12/7/1997
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
