This message is from the T13 list server.
> Yet still I've never seen this point raised without provoking enough > controversy that people give up and drop out of the conversation > without having learned to communicate. Yes, the vocal minority seems to win this battle. In T10/ADC, we fixed at least the direction problem by allowing an application client (host) to tell the device server (device) to send data whether data was implied by the CDB or not. The application client would then receive either data or a signal from the device server telling the application client to send data. This allowed the application client to effectively bridge another protocol WITHOUT interpreting the opcode. This solution worked for T10/ADC because of the explicit requirement of a "Transfer Ready" indication from the data recipient. This is a common problem to some of us, but our concerns seem to fall on deaf ears all to often. A transparent bridge that desires to ARBITRARILY bridge CDB's must have knowledge of both direction and transfer length. Sure you can code up a switch statement to decode direction and transfer length for ops that you know about. Sure, you can remember the most recent block size by sniffing mode pages. As Pat said, this only works if you have "...an a priori agreement to convey nothing but old standard ops...". A common solution, where available, has been "resort to PIO mode for ops that you aren't sure about". I have seen this problem on SPI to PATAPI bridges, USB to PATAPI bridges, SATA to PATAPI bridges, etc. Regards, David Hawks > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Pat LaVarre > Sent: Thursday, October 21, 2004 9:43 PM > To: [EMAIL PROTECTED] > Cc: forum at t13.org > Subject: RE: [t13] RE: comment on T10 ATA-passthru > > > This message is from the T13 list server. > > > > You guys just don't get it! > > I think I get it, for one? > > From what I can see of this conversation, I'm inclined to hope we're > actually all in violent agreement already? > > > I am a BRIDGE and I receive some whacked out command. It may be > > "standard" > > or it may be some vendor specific command. The information > about the > > data > > transfer, including byte count and transfer direction, were > handled by > > the host > > driver and I am far removed from that So if it's one of your > > "standard" > > commands, I have to look at the command to figure this > stuff out. If > > it's a READ10, > > say, I have to go get the damned MODE PAGES from the disk > or whatever > > to > > figure out how many BYTES because the CDB has a block > count. If it's > > some > > vendor-specific or future command I'm SOL. > > > > Can you hear us now? > > I did a bridge in 1998, and I suffered the same pain then. I > was doing > SCSI over USB to PATAPI, rather than ATA over SCSI to SATA or > PATA, but > I think that's not a significant difference for this issue. > > How to wholly support the vendor-specific and future standard > ops is an > intriguingly difficult concept to get across in words. I think many > people begin by believing the CDB should unequivocally express the > expected data copy direction and byte length. They think we > should not > have to add separate and technically redundant, and therefore > potentially contradictory, fields to convey that information. > > That perspective is both entirely correct and utterly irrelevant. > > The legacy of design for the ATA op and parameters, same as > the SCSI op > and parameters, has no history of unequivocally expressing > the expected > direction and length. Only an a priori agreement to convey > nothing but > old standard ops can escape the need to convey this info redundantly. > > Everybody should agree over this. It is a plain truth - a trivially > repeatable, empirical, scientific observation - not a matter > of debate. > It becomes plain - as it did here - so soon as you get to the > development stage of writing the code to pass thru an arbitrary > command. > > Yet still I've never seen this point raised without provoking enough > controversy that people give up and drop out of the conversation > without having learned to communicate. > > I wish I knew why. > > Pat LaVarre > http://members.aol.com/plscsi/cdbcomplete.html > http://ide-byte-counting.blog-city.com > >
