[8687] in linux-scsi channel archive
Re: sc_data_direction -- will we require it?
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Thu Apr 20 14:13:40 2000
Message-ID: <001301bfaaf0$9ae14230$4d0310ac@fairfax.datafocus.com>
From: "Eric Youngdale" <eric@andante.org>
To: "Matthew Dharm" <mdharm-scsi@one-eyed-alien.net>,
"Douglas Gilbert" <dgilbert@interlog.com>
Cc: <linux-scsi@vger.rutgers.edu>, <xiphmont@xiph.org>
Date: Thu, 20 Apr 2000 13:48:15 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
> 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 majordomo@vger.rutgers.edu
