> 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.
Could you treat UNKNOWN as implying both directions? This could imply a
performance hit in that you have to set up the bus to go both ways, but it
would be far better if we could come up with a means by which UNKNOWN
wouldn't screw up the bus. In the event that only READ is needed, then the
write phase would be unused.
> 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.
I always find it really annoying when kernel changes break user
applications. It seems that every time I upgrade a linux box, I end up
having to go and find a whole bunch of new utilities because the old ones no
longer function. I guess what I am saying is that I am not to hot on the
idea of *forcing* applications to be updated.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
