This message is from the T13 list server.
> Is there any case where the bridge > would not know the number of bytes that it wanted > (and therefore be able to parse the returned data correctly?). LOTS. Any command that moves data that was not fully standardised before either the bridge shipped or the device shipped falls into this bucket. The commands that will take us across the upcoming 2TiB barrier of 32 bit Scsi Lba's addressing 0.5KiB blocks leap to mind. Vendor-specific diagnostic commands leap to mind. The behaviour of commands when you remove media, vary capacity, vary block size, change out heads, leaps to mind. > not fully standardised before either ... shipped ... Come to think of it, I mispoke recently. Yes, by failing to standardise the way commands express byte count and direction, Scsi has managed to mess up even block commands. How many bytes does the Read(6) command x 08 00:00:00 00 0 move? Naturally you might think 0 blocks? Well the Scsi standard clearly disagrees: they say flatly this always means move x100 blocks. But some, indeed maybe more, shipped devices agree with You. > vary block size Forget "vary". If you depart from the de facto standard that is x200 (512) bytes per block, woe to you. If you depart even further than the CD/MO precedents of x400 and x800, then greater woe to you. > not fully standardised Please appreciate this is deeply ironic understatement. Myself I've been working Scsi only since 1994 and yet already I can't think of any single op I've seen implemented consistently, apart from read/write of nonzero counts of blocks. > Is there any case where the bridge > would not know the number of bytes that it wanted > (and therefore be able to parse the returned data correctly?). I'm not making this up. I'm speaking from years of pain. I'm talking about live paying customers for whom, as an industry, we successfully reinforced the impression we don't design PCs to do anything well except play games. Weird that your experience (focused largely on Ata, whole blocks, and OEMs not retail?) can be so dramatically more pleasant. My experience of plug 'n play failing for reasons like these is nothing like unique. I hear stories like these regularly at <[EMAIL PROTECTED]> and at <[EMAIL PROTECTED]> and at SBP-3 <[EMAIL PROTECTED]> and at <[EMAIL PROTECTED]>. > UDMA WORKS - over 1 billion ports use it today. These 1 billion ports use UDma to do what? Connect to Ata hard drives. Block read. Block write. xEC Identify to move in a single block of identifying data. And a wild variety of commands that transport no data. Ho hum. I mean, ok, UDma works in far, far more places than anything I've ever done ... but it doesn't yet work everywhere AtapiPio does. I'm definitely not talking billions. I am only talking millions. Percentage wise, that's nothing, I agree. But it's good enough to keep Me paid. Give me two dollars on the unit, and I'll retire. What we're talking about here is how to perpetuate the twenty year legacy I've inherited from the people who retired before me. I like a nutshell I once heard: with any Usb/Ide bridge we're adding another floor to a house of cards. > > How does the bridge decide if it should pass on 5 bytes or 6 bytes? > it parses the command and sees that 5 bytes were Yes if ... ... if we could know precisely how all the AtapiPio devices that matter to us interpreted commands when, ... if we could connect to the bridge all the same inputs that those AtapiPio devices use to alter their interpretation of commands, ... if we could afford to pay to include in the bridge enough hardware to duplicate perfectly the device's interpretation of commands. ... then yes the bridge could duplicate perfectly the device's interpretation of commands. But all those if's are silly. The task I've set myself here is to reproduce bug-for-bug the behaviour of locally attached AtapiPio devices. Except Pio has run out of gas, so I'm switching to UDma so I can raise the burst rate. But I don't work for a company anything like big enough to tackle the project of reconstructing the legacy that is Scsi interpretation. > all those if's are silly. Anyone been watching RBC run out of gas? I hear, same as Sff, that committee went off and redefined bit-identical commands to mean slightly different things. Vicious slander? Or true? If true, they're acting as if plug 'n play could always determine if an app wanted to be a Scsi host or an Rbc host. Utterly ridiculous. If we ever do go invent yet another command set, you've got my vote for requiring the devices to require the hosts to send as the first command a command identifying the command set. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
