Tejun Heo wrote: > Brian King wrote: >> For SAS, the scsi_host pointer in the ata port is NULL today, since libata >> is really not managing the scsi host, the LLDD is. I think the initialization >> model we want for SAS is a little different than the one you are heading >> towards on SATA. For SAS, I think we just want to be able to alloc/init >> and delete/destroy a SATA device a they show up on the transport, >> without tying it to initialization of the ata host. And this set of >> patches doesn't necessarily prevent that... > > Yeap, I tried to keep SAS bridge functions working. If SAS doesn't need > the host abstraction and wanna do stuff per-port basis, ata_port_alloc() > can be directly exported and separating out per-port register routine > shouldn't be too difficult, but I do think it would still be beneficial > to have ata_host structure in SAS case too for code simplicity if not > for anything else. I think having the ata_host structure for SAS is fine. It's just a matter of how much of what ends up in it actually gets used for SAS. >> Regarding holding all command execution on the host while performing eh, >> that doesn't seem to be a huge issue from my perspective, not sure if >> this would have a larger negative impact on others... Generally speaking, >> we shouldn't be entering eh very often, and it should only be happening >> if something went wrong. The biggest issue here might be ATAPI devices, >> since they tend to report more errors during normal running. The request >> sense for these devices for SAS is done without entering eh today. Would >> you want to move this into eh as well? > > No, not for SAS. The reasons why I put sense requesting to EH were... > > 1. to make fast path code straight forward (no qc reusing dance) > > 2. in native ATA, we have per-port EH thread so sharing is not a problem. > > As #2 is not true in SAS case, I think keeping sense requesting out of > EH is the right thing to do here. I still think that it's much > simpler/reliable to handle any exception case in a separate thread. I > think this in the long term should be solved by making EH per-request > queue (we of course will need mechanism to synchronize several EHs so > that we can take host-wide EH actions). Agreed. Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
