On 11/9/22 12:53 AM, Christoph Hellwig wrote: > On Tue, Nov 08, 2022 at 09:11:06PM -0600, Mike Christie wrote: >> + case NVME_SC_ONCS_NOT_SUPPORTED: >> + sts = PR_STS_OP_NOT_SUPP; >> + break; >> + case NVME_SC_BAD_ATTRIBUTES: >> + case NVME_SC_INVALID_OPCODE: >> + case NVME_SC_INVALID_FIELD: >> + case NVME_SC_INVALID_NS: >> + sts = PR_STS_OP_INVALID; >> + break; > > Second thoughts on these: shouldn't we just return negative Linux > errnos here? I wasn't sure. I might have over thought it. I added the PR_STS error codes for those cases so a user could distinguish if the command was sent to the device and it reported it didn't support the command or the device determined it had an invalid field set. -EINVAL/-EOPNOTSUP would continue to work like it does now where we can get those errors if the drivers determined it didn't support a operation or field or it thought we had an invalid setting. There is no specific error case I was hitting. I was just thinking it's nice for userspace to be able to do a PR op and if it got -EOPNOTSUP the driver didn't support the command and if it got PR_STS_OP_NOT_SUPP then the device didn't support it.
