Re: [PATCH v3 12/15] scsi: virtio_scsi: Convert to scsi_execute_cmd

[michael.christie@oracle.com]

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@mail.gmail.com/
>>
>> 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.