Re: [PATCH] sg.c to set direction more reliably (was Re: [PATCH] fusion update to current APIs)

[Jeremy Higdon <jeremy@sgi.com>]

On Tue, Jun 15, 2004 at 02:54:41AM -0400, Jeff Garzik wrote:
> 
> This is definitely moving backwards from the direction we want to go.

You really need to look at this in the context of the original thread.


> The entity creating the SCSI command needs to specify data direction, 
> _not_ tables hardcoded into the kernel.  Bart recently removed such a 
> table from IDE.

Yes.  In this case, sg is the entity.  This table causes sg to get
it right much more often than it did.

> These tables are fundamentally broken anyway, due to vendor-reserved 
> commands where the data directions are not specified, but simply "known" 
> by the submittor.

If the reply length is trimmed to the minimum, it will still work as
well as it does today.

> If /dev/sg's userland interface does not permit userland to provide the 
> data direction, then let's just consider it broken and move to Axboe's 
> bsg post-haste.

If you look at Documentation/scsi/scsi-generic.txt and then refer to
the v1 and v2 sg requests, you'll notice that you can't find a way to
specify direction.  Sg tries to figure it out, but often gets it wrong.
Note that in the v3 sg interface, data direction is explicitly
specified (as it should have been originally, imho).


For those new to the thread, the idea is to remove the direction
overrides from various host drivers and centralize them in sg.  If
we remove the direction overrides from the host drivers and do not
add this code to sg, then several apps that use the sg v1 and v2
interfaces will suddenly break.


jeremy