Messages in this thread | | | Date | Tue, 21 Mar 2000 13:31:55 -0500 | From | Douglas Gilbert <> | Subject | Re: 2.3.00p1/2.3.49: more problems concerning devfs & generic scsi |
| |
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/
| |