On Mon, Feb 13 2023, Max Gurtovoy <> 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
