On 11/16/20 9:05 PM, Paolo Bonzini wrote:
On 16/11/20 20:03, Hannes Reinecke wrote:
+ case SCSI_HOST_TARGET_FAILURE:
+ *sense = SENSE_CODE(TARGET_FAILURE);
+ return CHECK_CONDITION;
+ case SCSI_HOST_RESERVATION_ERROR:
+ return RESERVATION_CONFLICT;
+ case SCSI_HOST_ALLOCATION_FAILURE:
+ *sense = SENSE_CODE(SPACE_ALLOC_FAILED);
+ return CHECK_CONDITION;
+ case SCSI_HOST_MEDIUM_ERROR:
+ *sense = SENSE_CODE(READ_ERROR);
+ return CHECK_CONDITION;
Can these actually be visible to userspace? I'd rather avoid having
them in QEMU if possible.
Otherwise, the patches are completely sensible.
And I did it exactly for the opposite purpose: rather than
painstakingly figuring out which codes _might_ be returned (and be
utterly surprised if we missed some) add an interpretation for every
_possible_ code, avoiding nasty surprises.
And that certainly makes sense too.
On the other hand it'd be nice if Linux was clearer about which the
SCSI_HOST values are part of the userspace API and which are just an
(ugly) implementation detail.
Oh, I certainly agree with that.
But that is more of a long-term prospect; I do see some discussions
ahead if one were to try it. Especially as (like DID_BAD_TARGET and
DID_NO_CONNECT) have no clear distinction between them, and are used
more-or-less interchangeably.
But a clear definition of these values would inevitably lead to a change
in various drivers, which then would lead to a change in behaviour, and
a possible user-space regression.
So not that easy, sadly.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
