Le Wed, 22 Oct 2008 14:21:57 -0700, Chandra Seetharaman <sekharan@xxxxxxxxxx> a écrit : > > On Wed, 2008-10-22 at 21:54 +0200, Christophe Varoqui wrote: > > It seems to me the device handler infrastructure proposes to > > translate scsi error codes from requests generated by the device > > handler itself. I > > No, the handler doesn't generate the requests. > > Device handler's check_sense() function is called from the > scsi_error.c:scsi_check_sense() function whenever a sense code is > returned from the device (on normal I/Os). > > When in the sense function, the device handler can do any action (like > closing the other path(s)) and returning an appropriate error code > (such that dm doesn't retry the I/O on other paths). > Thanks for the clarification. I shouldn't have stopped after reading the hp_sw handler, which does not implement a .check_sense So now, device handlers indeed look promising. I still see difficulties though : 1/ reservation conflict is a scmd status, and as such short-cuts the scsi_check_sense function altogether. Sould we hook device handlers to status parser too ? 2/ should we create an trivial device handler and load multi-handlers multipath maps or should we make this device handler implicitly always active ? Regards, cvaroqui -- To unsubscribe from this list: 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
