lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:0.021 / U:62.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site