Douglas Gilbert wrote: > Brian King wrote: >> I think you really need a >> libata API that the LLDD can call from its queuecommand function >> to translate and send a command, which then calls back into the LLDD >> to send the FIS to the hardware. This allows for all SAS/SATA devices >> under the same HBA to show up under the same scsi_host. > > Brian, > I don't think a SATL is that easy. That is essentially the API that libata has today. Existing SATA drivers have a queuecommand routine that invokes a libata API to send a taskfile to the hardware. > One SCSI command can > translate into zero or more ATA commands. If it translates > to multiple commands, then there is the possibility of an > error prior to the last in the sequence of ATA commands > (how to report; rollback needed ?). The SATL needs to hold > state and needs a service thread if it is to support the > IMMED bit on some commands (e.g. START STOP UNIT). I guess I don't see these problems as unique to SATA drives attached via a SAS adapter, which is what my patchset is trying to implement, but rather general libata issues. Reading Jeff's response, it sounds like the service thread issue is already being worked in another manner. Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
