Tejun Heo wrote: > Association to SCSI host is done via pointer now even for native ATA > case, so this should be easier for SAS. What I'm worried about is how > EH gets invoked. libata depends on EH to do a lot of things including > probing, requesting sense data, etc. How should this work? 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... > SAS attached libata port shares EH with the SAS SCSI host, right? How can Right. > we connect SAS EH with libata EH and would it be okay for libata EH hold > the SCSI EH (thus holding all command execution on the host) to handle > ATA exceptions? Currently, ipr calls ata_do_eh from its eh_device_reset_handler function. This seems to work well enough with the testing that I've done, but it would certainly be nice to get to a more layered EH approach, where we could possibly have pluggable error handlers for different device types. 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? 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
