Eric Youngdale wrote:
>
> There is also an older depreciated ioctl style of generics interface
> which could also use the same logic as it has the same problem. Building
> the table into sg is probably not the best place for it, but the table could
> go in the mid-layer as a function and then both bits of code could call into
> it to figure out the data direction.
The mid-level would be the optimum place for such a table. Would it
need to take into account the device type? As you point out below,
it still doesn't cover the vendor specific commands.
On reflection, the data direction hint that apps give to the pass
through mechanisms should be an accurate indicator. If a
bi-directional indication is given then it may be safe to assume
a READ like operation. [In the new sg_io_hdr interface there is
a bi-directional transfer flag. The documentation tries to make
it clear that the bi-directional transfer is only between the
user space and the kernel buffers and that the underlying SCSI
layers will assume read direction.] So if Monty confirms that
cdparanoia never sends a write direction command under the guise
of a bi-directional transfer then it may be worth re-instating
the SCSI_DATA_READ/WRITE flags in existing sg_header case. Same
logic would apply to SCSI_IOCTL_SEND_COMMAND and CDROM_SEND_PACKET.
[Actually looking at the SCSI_IOCTL_SEND_COMMAND ioctl() code,
this is what it is doing now in 2.3.99-pre5.]
The linux-kernel thread that I referred to in my previous post
on this thread exposed 2 issues:
- the data direction issue being discussed here
- a low level driver panic when (sg_list > 0) && (xfer_len == 0)
Again on reflection it was probably wrong to be stampeded
on both these issues. IMHO both the aha1542 and the 53c8xx
drivers are wrong to panic in the latter case since the
sg_list state when (xfer_len == 0) is not their concern
as kernel buffer resource control is the responsibility of
the upper layer. Still the latter issue has been addressed
but it is causing problems for some SANE users.
Forcing the issue on the data direction flag (the effected
application authors know where to find me :-) ) may well
help us in the medium to long run.
> It would be helpful if the people who knew the most about the
> limitations of the various tables scattered through the various low-level
> drivers would pick one that is believed to be the most accurate and
> comprehensive. The thing I still don't know about is how to handle vendor
> specific commands - in particular something like cdparanoia is probably
> going to use these quite frequently, and we really haven't solved everything
> by adding the table to resolve ambiguities.
>
> I had kind of hoped that all drivers could tolerate (with the possible
> loss of performance) having the flag set to UNKNOWN. In this way we would
> be assured of a fallback position that would at least function without
> screwing up the system. In conjunction with a table, we could set the
> direction correctly for non-vendor specific commands, and force it to
> UNKNOWN for vendor specific commands. This would eliminate the possibility
> of an ill-behaved application screwing up the system.
As Gerard pointed out, the reward for getting the data direction wrong
is possibly a SCSI bus reset rather than a crash (in his drivers). Still
if that SCSI bus holds a disk with the root file system this is
discomforting, especially if there are retries.
Perhaps I did not fully understand Matthew concerning the USB mass storage
driver, but it sounded like the USB architecture could not handle the
UNKNOWN data direction. Or is that an overstatement?
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
