Re: cdparanoia patch for ahci(4)/siis(4)

Alexander Motin wrote:
> Scott Long wrote:
>> Alexander Motin wrote:
>>> CAM reports SCSI protocol for ATAPI devices at this moment. It is not
>>> good probably. but changing it now may be painful. Checks like
>>>     d->ccb->cpi.transport == XPORT_ATA ||
>>>     d->ccb->cpi.transport == XPORT_SATA
>>> should be for now. "ata" hack should also stay there for now, as
>>> ATAPICAM emulates SCSI transport now, but not a new ATA one.
>> What protocol should CAM be reporting for ATAPI devices?  It is SCSI.  I
>> don't understand why we have to keep on diverging from the goal of
>> having a unified and consistent interface here.
> 
> ATAPI supports both ATA (partially)

Not really, just enough to get it going into PACKET mode.  The SCSI
emulation in ATAPI drives has been very good for the past 10 years, as
they have to be MMC compliant in order to work with the common Windows
software.

> and SCSI command sets. And before
> main SCSI commands can be executed, ATA identification and configuration
> should be done.

This is a detail that happens internal to CAM and long before the device
is made available to the user.

> Now SATA XPT fetches ATA IDENTIFY and sets respective
> transfer mode, but it is tricky now for other code to differentiate
> ATAPI devices from plain SCSI.

Again, there is no need.  An application can always look at the protocol
transport data, see that it's SATA/ATA, and do an XPT_ATA_IO command.
Adding yet another protocol definition only complicates things for no
benefit and no portability.

> From the one side transfer negotiation is
> indeed only a transport feature, but from other side, as in this
> cdparanoia case ATAPI/SCSI difference somehow affects error handling
> (haven't looked actually why).
> 

As we have discussed many times, ATA error reporting is primitive at
best, and vastly inferior to SCSI error reporting.

Scott