I have already done the sense_buffer mod on 2.2.10-ac7
and from my first check into the SCSI sub-system drivers
only one needs a change because of it. [I am too
embarrassed to mention which one that is :-)]. So far so
good.
> But the "actual bytes transferred" does not make
> sense in SCSI due to the MODIFY DATA POINTER message. So does not make
> sense the calculation of any residual based on some DMA counter for the
> same reason. Even if the MODIFY DATA POINTER is rarely supported and/or
> used, we must consider it.
>
> You only need to be aware of the amount of data that has been transferred
> for some situations involving tape devices (stream devices). For these
> situations there are flags and REQUEST SENSE data that allow to deal with
> them gracefully.
If a transfer count is good enough for CAM-3 it should
be good enough for us. [I prefer an absolute count
(defaulting to 0 for low level drivers that don't
support it) while the rest of the world prefers a
residual count. I will go with the majority on this
point.]
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
CAM-3 Working draft, rev 3 16-Mar-98
page 144 section 11.8.1 in
typedef struct ccb_scsiio3 {
...
CAM_I32 cam_resid;
...
} CCB_SCSIIO3;
- cam_resid
The data residual length member contains the difference
in twos complement form of the number of data bytes
transferred by the HA for the SCSI command compared
with the number of bytes requested by the CCB cam_dxfer_len
member. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Both Doug Ledford (aic7xxx) and Bob Frey (advansys) have
indicated that they can provide this number. On the
application side, Joerg Schilling (cdrecord), Monty
(cdparanoia) and David Mostang (sane) would like to
know this number.
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/