On Thu, 20 Apr 2000, Douglas Gilbert wrote:
> Forcing the issue on the data direction flag (the effected
> application authors know where to find me :-) ) may well
> help us in the medium to long run.
I agree here. I think we have to force the issue to get applications
to make the change.
> As Gerard pointed out, the reward for getting the data direction wrong
> is possibly a SCSI bus reset rather than a crash (in his drivers). Still
> if that SCSI bus holds a disk with the root file system this is
> discomforting, especially if there are retries.
I agree that this is discomforting, but I think it may be the only way.
And the fact that we maintain functionality is an important thing -- I'm a
strong believer in the "recover from errors and go on whenever possible"
theory of design.
> Perhaps I did not fully understand Matthew concerning the USB mass storage
> driver, but it sounded like the USB architecture could not handle the
> UNKNOWN data direction. Or is that an overstatement?
It's a slight overstatement. Let me put it this way: The USB Mass
Storage driver _must_ know from somewhere which way the data transfer is
going to be. Right now, it has its own internal table. I don't like this
approach because I cannot verify that this table is accurate, nor can I
handle vendor-specific commands. Thus, I would like to use the
sc_data_direction flag. However, if I use this flag, then I cannot handle
the UNKNOWN condition.
So yes, the USB Mass Storage driver would not be able to handle a command
where sc_data_direction is UNKNOWN. It would reject that command,
probably setting result to DID_ERROR<<16. I haven't implemented the
behavior to rely on the sc_data_direction flag yet. I'm still waiting for
this discussion to come to a conclusion before I do so.
At the very least, I think Alan Cox's idea of consolidating all the
various driver-level tables into a mid-level table is a good start.
Secondarily, we need to force the issue with application developers to
_make_ them set the flag.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
Oh great modem, why hast thou forsaken me?
-- Dust Puppy
User Friendly, 3/2/1998
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
