> Gerard Roudier wrote:
> > 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.]
And if the majority is loose, such a "moutons de Panurge" bahaviour makes
you as loose as the majority.
Just think about a device that uses MODIFY DATA POINTER message and let me
know how you will calculate your residual/actual data counter and how the
application will understand about the counter value when the transfer is
partial.
No need to consider MDP, btw: a device is perfectly allowed to RESTORE
the previously saved DATA POINTER and then to complete the command, even
if it is stupid. Let me know how the majority will calculate the residual
in such a _legal_ (but stupid) behaviour of the device.
What about intelligent controllers that donnot provide this information?
As an example, such a stupid "moutons de Panurge" behaviour led most SCSI
device drivers to _wrongly_ associate the CmdQueue flag to the target. The
CmdQueue bit must be associated to the logical unit that is the _real_
device.
> 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
So can provide this number the aic7xxx of FreeBSD and the aha(1542) device
driver of FreeBSD, it seems. So, very probably associate the CmdQueue to
the target all the drivers that have been mentionned.
It is not the majority, as far as I can tell, unless you consider that
that Adaptec stuff and guys represents the majority.
> application side, Joerg Schilling (cdrecord), Monty
> (cdparanoia) and David Mostang (sane) would like to
> know this number.
AFAIK, the MDP is still in the SCSI specs. Even if the MDP has been used,
we can calculate such a number, but it can only indicate if the transfer
has been complete or partial (kind of error checking). It must not be used
for anything else, unless the application ckecked that the MDP is not
enabled for this device, and made sure that the involved SCSI device
driver is smart enough not to be confused by a SCSI device that changed
the data pointer by a restore just before completing the IO.
By the way, the CAM3 method is basically some reformulation of some DEC
access method. It can be wrong or just loose in some places and some
non-sense may have been missed by the SCSI committee.
Gérard.
-
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/