This message is from the T13 list server.
I agree... I think we are getting to the purpose of the CDB transport mechanism at this point. My current vision is manufacturing and maintenance. This would mean that SCSI would be the normal mode of operation for reading and writing the media. However, in the case of a bridged (P/S)ATA device (USB, 1394, SAS, etc) you may want to tech support the device by issuing a SMART command. Using CDB pass-through, I think this can be done using existing standard driver pass-throughs. It would also allow device failure diagnosis without opening the box and removing the ATA device. Our major use will be for vendor specific commands... At this point, I do not really see this being used in a performance environment. So, the devices will already have to deal with the SCSI presentation issue. The one case I can see is if there are many drives presented as one device by the SCSI-ATA bridge. Then there would need to be a mechanism for addressing the individual ATA drives. I think in this environment (which is starting to look like a RAID), there is a bigger problem to solve. ------------------------------------------------ Curtis E. Stevens 20511 Lake Forest Dr. #C 214-D Lake Forest, Ca. 92630 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: [EMAIL PROTECTED] -----Original Message----- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 7:28 PM To: Curtis Stevens Cc: Sheffield, Robert L; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [t13] SAT: Reminder - Teleconference Thur 8/12 9:00 AM PDT Curtis Stevens wrote: > Just a heads up, I posted a proposal (04-260.PDF) for > documenting how a SCSI command maps to an ATA command. Another quick comment. Sorry I didn't include this in the first email. Quoting... > The host shall set the DEV bit to 0 and the device shall ignore the DEV > bit. This is required because the presence of multiple devices cannot be > detected. If multiple devices are present on a single cable, the host > may indicate this to the host software by reporting multiple LUNs. If > there are multiple LUNs, the bridge shall set the DEV bit to the > appropriate value before setting the ATA command register. I agree with this, but for a reason not stated: If the SAT translator software exports ATA devices as individual SCSI targets (rather than LUNs), then the DEV bit is irrelevant at the ATA passthru level. The low-level ATA driver _must_ set or clear the DEV bit as appropriate, and the SCSI I/T nexus provides all the information necessary to do so. And a parting shot: existing SATA controllers _do_ occasionally present SATA devices as master/slave. Several (Intel, SiS, VIA, others?) have a compatibility mode that in current hardware is often enabled by default, presenting two SATA devices as a master/slave pair. Jeff
