Alan Cox wrote (in response to [EMAIL PROTECTED]): > > > let me reiterate my earlier protestation. sg is a gender-neutral > > conduit by which a user-space program can send commands > > and data to a device and receive status and data back. > > if someone is programming at this level and doesn't know > > in which direction data is supposed to flow, then he or she > > is programming at the wrong level and is very likely in the wrong > > profession. > > The old version of the interface doesnt really let people tell them With the older sg_header interface if the count (3rd agument) on the write() > (sizeof(sg_header) + length_of_scsi_command) then data is being written to the device. OTOH if sg_header::reply_len > sizeof(sg_header) then data is being read from the device. If neither condition is met then no data will be transferred (e.g. Test Unit Ready). If both conditions are met then we have a quandary which can be resolved by interpreting the data direction as a read. [I am still awaiting a reply from Monty on this issue with cdparanoia. No-one reported a "paranoia" problem between 2.3.43 and 2.3.99-pre3 when sg_header did send through a deduced data_direction flag.] The only practical reason for a bidirectional transfer is to detect a short read transfer. Passing back the residual count on the transfer (as done in the newer sg_io_hdr) is a better solution but is not supported by the majority of adapters yet. Same logic applies to SCSI_IOCTL_SEND_COMMAND [SISC] while CDROM_SEND_PACKET [CSP] has a data direction flag. So, as far as I can see, a data_direction flag is just a cleaner way of passing information that is provided in a more awkward fashion by sg_header and SISC. Actually the data_direction flag is worse because in the cases of sg_io_hdr and CSP they allow an UNKNOWN direction value. > > as soon as one starts building "general-purpose" tables into > > sg or lower levels, one is left with yet another maintenance > > headache and something that is bound to be wrong for one > > or other application. > > Well you can put the table in each driver (probably differing per driver > in detail), or you can put it in the sg code where at least its consistent. > > It shouldnt be overriding cases where the sg code is provided direction info > by the client so your complaint IMHO isnt valid As outlined above, the sg client is always providing direction info to the sg_header interface (in one case overspecified). There are 5 data transfer states: 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**] 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. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
