Re: [virtio-comment] Re: [PATCH v10 03/10] admin: introduce group administration commands

[Cornelia Huck <cohuck@redhat.com>]

On Mon, Feb 13 2023, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:

> On 13/02/2023 15:13, Cornelia Huck wrote:
>> On Mon, Feb 13 2023, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>> 
>>> On 13/02/2023 14:42, Cornelia Huck wrote:
>>>> On Mon, Feb 13 2023, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>>>>
>>>>> On 13/02/2023 10:16, Michael S. Tsirkin wrote:
>>>>>> On Mon, Feb 13, 2023 at 02:54:47AM +0200, Max Gurtovoy wrote:
>>>>>>>> For some system calls and library functions (e.g.,
>>>>>>>>            getpriority(2)), -1 is a valid return on success.  In such cases,
>>>>>>>>            a successful return can be distinguished from an error return by
>>>>>>>>            setting errno to zero before the call, and then, if the call
>>>>>>>>            returns a status that indicates that an error may have occurred,
>>>>>>>>            checking to see if errno has a nonzero value.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Description is already good enough to describe what they are.
>>>>>>>>> Can we please drop Linux wording?
>>>>>>>>
>>>>>>>> But why should we? It's where 22 comes from so this way people are not
>>>>>>>> wondering about the value, and it's somewhat helpful for Linux
>>>>>>>> developers.
>>>>>>>>
>>>>>>>
>>>>>>> I also think we should not mention Linux. I don't think it's mentioned
>>>>>>> currently in the spec and no good reason to do so now.
>>>>>>
>>>>>> But we do: fuse, input at least both do.
>>>>>>
>>>>>>> Also value of 22 is not mandatory for this EINVAL status code. It can be
>>>>>>> just 1 (the first number after the OK status).
>>>>>>
>>>>>> 22 makes it a tiny bit easier for kvm. So why not.
>>>>>
>>>>> Because people comment on that in the review :) and because a
>>>>> specification should be OS independent.
>>>>> 22 might be EINVAL in Linux but a success in MyOS is my lucky number is 22.
>>>>>
>>>>> not a big issue for me, but I prefer to have a cleaner spec than maybe
>>>>> simplify something in a very specific OS.
>>>>
>>>> Well, my take is:
>>>> - we have to pick *something*
>>>> - using EINVAL == 22 is very convenient for one of the most common (the
>>>>     most common?) implementors
>>>> - noting that we're trying to follow what Linux uses makes it clear what
>>>>     to pick for any new return codes
>>>>
>>>
>>> Can we agree on 22 without mentioning Linux ?
>> 
>> See my third point above: we want people to be aware why we chose 22, so
>> any new values will match up as well.
>
> Why we need people to be aware ?

people == people adding new error codes

>
> In NVMe spec for example there are many status codes (~30-50) and people 
> are not aware why the committee choose  0x02 for "Invalid Field in Command".
> And frankly, I don't think they care.
>
> My point is that we need to make our lives, as spec developers and 
> maintainers, easier.

And that's why I think we should keep the proposed wording :) I think it
will make the life of Future Me easier.