This message is from the T13 list server.
> -----Original Message----- > From: Hale Landis [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 29, 2003 10:10 AM > To: [EMAIL PROTECTED] > Subject: RE: [t13] ATAPI byte counting > > > This message is from the T13 list server. > > > On Wed, 29 Jan 2003 09:34:16 -0600, Elliott, Robert (Server Storage) > wrote: > >This message is from the T13 list server. > > > >The SCSI architecture model requires byte granularity for > >data transfers by all SCSI transport protocols (see sam3r04 section > >5.4.3 - Data transfer protocol services). > > > >If ATAPI lacks this, it's an(other) area where it's not quite SCSI > >compliant. > > Now we are back to one of the most basic questions regarding > ATAPI: Is it SCSI or is it something else? The original > definition of ATAPI was based on the idea that it was not > really SCSI - it was something else that looked like SCSI on > the surface but was less complex. (Sound familar? Look at > SATA/SAS marketing hype.) > > T10 could resolve this problem by identifing ATAPI as one of > the SCSI transports. But T10 has never done this. The only > recognition given by T10 to ATAPI is some brief comments in > the MMC-x documents. I almost put together a T10 proposal to add ATAPI to the list of T10 protocol identifiers. But since we have no ATAPI-specific data strucutures yet requiring such a definition, I didn't proceed. (these would be: protocol-specific mode pages, Access Control transport IDs, Extended Copy target descriptors, etc. - not features used by ATAPI devices at this time). Similarly, I started to request INQUIRY version descriptors for ATA/ATAPI-n standards. But, IDENTIFY PACKET DEVICE already returns that information, so I'm not sure we should duplicate it inside the SCSI INQUIRY data. SAM-3 is no longer describing protocols without autosense, so in one sense it's too late to add ATAPI recognition to SCSI. SAM-2 is the last architecture revision to which ATAPI could conform without major changes. > So I think we (T13) must say that ATAPI is "SCSI like". And > when talking about parallel ATA/ATAPI we must say that the > physical ATA interface is able to transfer only 2 bytes at a > time. Therefore, all data transfers are an even number of > bytes. An ATA/ATAPI host (application software or OS device > driver) that attempts a data transfer for an odd number of > bytes must be aware that the physical interface does not > suppot this and this software must be prepared to recognize > that there may be a pad byte at the end of the transfer. > > I don't see T13 doing anything to change the ATA/ATAPI > parallel interface data transfer protocols. It's obviously survived without byte granularity so far. > But what about SATA? Has this been addressed there? Or is > ATAPI executed over SATA also just "SCSI-like"? The PIO Setup FIS has a 2 byte transfer count field containing a number of bytes. It lists no restriction on the values in that field. It mentions transferring an odd numbers of words later (but not bytes). The DMA Setup FIS has a 4-byte DMA transfer count field, but decrees that "bit zero must be zero." The Data FIS description says "The Serial ATA protocol does not permit for the transfer of an odd number of bytes." You could probably relax some of these rules to support odd byte transfers pretty easily. It's got the length fields that could properly indicate them. > Hale > > *** Hale Landis *** www.ata-atapi.com *** -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott
