On Thu, 2007-01-18 at 00:49 +0900, Tejun Heo wrote: > James Bottomley wrote: > > This looks perfectly fine as a possible solution. Is there any reason > > not to initialise qc->dma_dir unconditionally from the SCSI command? > > That should work too. I did what I did because it was more in line with > what the current code assumed and initializing the field on qc alloc > seemed like a good idea with or without unconditional qc->dma_dir = > scmd->sc_data_direction because not all commands are translated from > scsi command. Sure, I agree with the initialisation (although it should perhaps be initialised to an error value we can detect just in case there are other paths where it would leak through uninitialised ... we'll still get cockups if a command with data ever goes through as DMA_NONE. > > The only potential problem is DMA_BIDIRECTIONAL, which we don't use > > (yet) ... but if it ever did come down libata will do the wrong thing > > anyway. > > If that ever happens, libata probably should emulate it using multiple > commands, I guess. This really depends on where SATA is going. Current SCSI bidirectional commands are the preserve of the complex command sets I don't believe even a SATA device would ever emulate. On the other hand, we're planning to use bidirectional in SGv4 for frame in/frame out type packets that are used to control expanders. So the interesting question is whether SATA would ever want to drive expanders? For the low end, given the lack of success of the port multipliers which are effectively a poor man's expander, I guess not ... but, since most SAS/SATA cages seem to be coming with built in expanders, I can see that changing. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
