This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ] > Re: RE: [t13] another example for Pat >>> McGrath, Jim 04/13/02 21:49 PM >>> > how SCSI commands are transported across various protocols is actually a T10 responsibility. Other committees, like T13 for ATA and T11 for Fibre Channel, will implement what is required, but the requirements come out of T10, since they control SAM and the command sets. So I'd bring up the issue first with T10, and get their direction. Interesting twist, thank you. I agree T10 Sam should explicitly discuss whether a Scsi-over-whatever protocol has to be able to copy an arbitrary count of bytes. Either the Scsi-over-whatever device has to be able to copy just 5 bytes In or else the Scsi-over-whatever host has to know when it has to double-buffer. I'll go ask the T10 folk about that, thank you again. Pat LaVarre >>> McGrath, Jim 04/13/02 21:49 PM >>> Pat, I think we're making some progress here. My contention has been that this is a command level issue, and you appear to agree. My problem here is that I'm not convinced its a practical problem, since it would appear that SCSI commands are executed perfectly fine today on a whole variety of physical interconnects. So why is this not a problem for them, while it is a problem for ATA (as you contend?) True, parallel SCSI has a message to tell the receiver that the last data word (16 bits) was only a single bye with a pad. But I've never seen anyone use this approach. I'd need more information to make a good guess myself, but my intuition tells me that most SCSI implementations probably handle this by only execution the "strange" data commands (e.g. INQUIRY) while in 8 bit transfer mode (at power up/after reset when 8 bit is the default, and befor wide negotiation). At the end of the day how SCSI commands are transported across various protocols is actually a T10 responsibility. Other committees, like T13 for ATA and T11 for Fibre Channel, will implement what is required, but the requirements come out of T10, since they control SAM and the command sets. So I'd bring up the issue first with T10, and get their direction. If T10 thinks there is a problem, then I'm sure T13 will implement a solution. But since T13 is not responsible for SCSI command set issues, I doubt they're going to want to "patch" a protocol to fix a command layer issue - especially without input from the people who do control the command layer. To me that's only common sense. Jim
