Re: [PATCH] consolidating data direction tables

2001-02-14 Thread Douglas Gilbert
Jeremy Higdon wrote: > > [snip] > > I was reading Documentation/scsi-generic.txt in 2.4.1. I didn't see > anything about direction in the "new sg_header". Is there something > newer? > > | The new sg_header offered in this driver is: > | #define SG_MAX_SENSE 16 > | struct sg_header > | { Jer

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Daniel Eisenbud
On Wed, Feb 14, 2001 at 08:16:30AM +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > However, in light of other email in this thread, it looks like maybe the > > table can go altogether, so hopefully this question is now moot. > > Oh yes, I saw the mail you are refering to. > Let me put it

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Oliver Neukum
> However, in light of other email in this thread, it looks like maybe the > table can go altogether, so hopefully this question is now moot. Oh yes, I saw the mail you are refering to. Let me put it this way: If we get rid of 'direction unknown' then I'd be comfortable with killing it. I'll put

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Oliver Neukum
> > This means that it would be compiled into the kernel several times. > > You should add it to the core scsi code and _not_ declare it static. > > I considered doing it this way. As I saw it, it's a tradeoff between > including the code even if none of the drivers in question are > configured i

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Jeremy Higdon
On Feb 13, 9:40am, Douglas Gilbert wrote: > > Daniel, > Does that driver take any account of Scsi_Cmnd::sc_data_direction_flag? > All upper level drivers (including sg) in the lk 2.4 series set > the corresponding Scsi_Request::sr_data_direction_flag . > > In the case of sg in lk 2.4, it suppor

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Daniel Eisenbud
On Tue, Feb 13, 2001 at 10:24:14AM +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > The attached patch does two things: it creates a new header file called > > > scsi_dataout.h, which has a single copy of the switch statement (as a > > > static function -- is that all right?) and is included

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Daniel Eisenbud
On Tue, Feb 13, 2001 at 09:40:36AM -0500, Douglas Gilbert <[EMAIL PROTECTED]> wrote: > Daniel Eisenbud wrote: > > > > Eight different SCSI drivers have large switch statements to determine > > the direction in which data will be transferred for a given SCSI > > command. I discovered this when tr

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Douglas Gilbert
Daniel Eisenbud wrote: > > Eight different SCSI drivers have large switch statements to determine > the direction in which data will be transferred for a given SCSI > command. I discovered this when trying to figure out why the MESH > (powermac SCSI) driver locked up when (and only when) trying

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Alan Cox
> That could be done, but you'd never be able to drop these tables. And ? > I'd prefer a clean break to the new interface. It's better. > Doug Gilbert is working on it. You drop them after 2.6, much more polite - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Alan Cox
> > Has a direction bit been considered for Linux SCSI infrastructure? > > It would be useful to be able to specify this starting at the sg > > level on through to the hba layer. > > It's there but not visible through the sg driver. That would make sense for 2.5 > > We currently support a RAID

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Oliver Neukum
On Dienstag, 13. Februar 2001 10:42, Jeremy Higdon wrote: > On Feb 13, 10:24am, Oliver Neukum wrote: > > > We currently support a RAID which uses vendor unique commands to do > > > device management. We need special versions of drivers that understand > > > the implied direction of the vendor uni

RE: [PATCH] consolidating data direction tables

2001-02-13 Thread Ballabio_Dario
Neukum; Daniel Eisenbud; [EMAIL PROTECTED] Subject: Re: [PATCH] consolidating data direction tables On Feb 13, 10:24am, Oliver Neukum wrote: > > > We currently support a RAID which uses vendor unique commands to do > > device management. We need special versions of drivers that und

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Jeremy Higdon
On Feb 13, 10:24am, Oliver Neukum wrote: > > > We currently support a RAID which uses vendor unique commands to do > > device management. We need special versions of drivers that understand > > the implied direction of the vendor unique commands. Under Irix, the > > ds interface explicitly spec

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Oliver Neukum
> > mac53c94 driver.) The other drivers in question may or may not be able > > to recover from the missing item in their tables, but the fact that > > these tables are in the drivers at all implies that they work best if > > the tables are correct. Some drivers need a direction. If you don't kno

Re: [PATCH] consolidating data direction tables

2001-02-13 Thread Jeremy Higdon
On Feb 12, 8:49pm, Daniel Eisenbud wrote: > > Eight different SCSI drivers have large switch statements to determine > the direction in which data will be transferred for a given SCSI > command. I discovered this when trying to figure out why the MESH > (powermac SCSI) driver locked up when (an

[PATCH] consolidating data direction tables

2001-02-12 Thread Daniel Eisenbud
Eight different SCSI drivers have large switch statements to determine the direction in which data will be transferred for a given SCSI command. I discovered this when trying to figure out why the MESH (powermac SCSI) driver locked up when (and only when) trying to burn a CD-R in disk-at-once mod