On 12/23/22 9:57 AM, Christoph Hellwig wrote: > On Sun, Dec 18, 2022 at 03:40:48PM -0600, Mike Christie wrote: >> It looks like a hack around scsi_scan_host not removing devices. >> Going forward, it looks like we can remove the inquiry code by having >> scsi_scan_host be able to remove devices that are no longer returned. > > Yes, that's the place to do it. I can see arguments for and against > that, but doing it from and LLDD (and including sd.h in the LLDD > implementation!) just doesn't make sense. > >> I was thinking to handle the DID_BAD_TARGET use case above and this type >> of issue: >> >> https://lore.kernel.org/linux-scsi/CA+PODjqrRzyJnOKoabMOV4EPByNnL1LgTi+QAKENP3NwUq5YCw@xxxxxxxxxxxxxx/ >> >> maybe we want to have a driver level BLIST like: > > Maybe instead of a blist we just need better way to communicate > this rather than abusing DID_BAD_TARGET? Yeah, after I sent the blist email I looked into qemu and the DID_BAD_TARGET uses more and we can do more what you are thinking. I'm going to do: 0. qemu only uses VIRTIO_SCSI_S_BAD_TARGET (this gets converted to DID_BAD_TARGET) when the device does not exist, or if you are using a sg device and it returns DID_BAD_TARGET. 1. Most driver uses of DID_BAD_TARGET are when the device is missing, disconnected, timedout, or the bus:target_id:LUN value was not supported by the driver. So I was going to rename DID_BAD_TARGET to DID_INVALID_DEVICE/DID_DEVICE_INACCESSIBLE for those cases. 2. Create a new DID_ error code for the other use cases where the driver meant that the target did something incorrect/invalid like send a invalid response. In the scan code then we know if we got a DID_INVALID_DEVICE the device is not there anymore so we can remove it.
