David S. Miller wrote:
> That would work and long term is probably the right answer, but
> then how do you deal with vendor specific commands ?
>
> SCSI_DATA_UNKNOWN is a suitable "I don't know" response. The
> only loss is one of performance, this is the case for the two
> instances drivers use this information for:
>
> 1) To set PCI_DMA_* in pci DMA mapping calls, the DMA-mapping.txt
> doc explicitly allows PCI_DMA_BIDIRECTIONAL with the caveat that
> it may have a performance impact.
>
> For scsi generic, and vendor commands, big deal.
Sg has an additional interface in 2.3 in which the data
direction is specified. The current driver passes that
information through to the mid-level and beyond. What
happens if the app writer gets it wrong or, the data
direction of a vendor specific command changes between
models? The CAM, UDI and ASPI pass-through interfaces
all have a similar data direction flag. Perhaps Gerard
can tell us what happens in FreeBSD (CAM3) if that
flag is incorrectly set?
Crashing the kernel in such circumstances seems a bit
extreme.
> 2) By scsi drivers specifically to give a hint to the card as to
> what data transfer direction to expect.
>
> In all history they have been able to deal with not knowing, so
> they can handle this case by implication. :-)
>
> So if you just make the SG driver use SCSI_DATA_UNKNOWN all should
I'm testing out a retrograde patch to do just this on
the original sg_header interface. That should cure the
SANE problem. Hopefully it will be ready tomorrow.
The SCSI_IOCTL_SEND_COMMAND ioctl() probably needs attention
for the same reasons.
> be ok. Leaving it at SCSI_DATA_NONE when there is a data buffer
> attached to the request is a BUG() and needs to be fixed.
Still trying to track down how that scenario can happen.
Some SANE backends go direct to sg and could set a sg_header
object so data looks like it is flowing both ways irrespective
of whether a command data transfer direction is like a READ,
WRITE or has no associated data transfer.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:34 EST