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

[Max Gurtovoy <mgurtovoy@nvidia.com>]

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.

> > Developers should be able to read the specification and find out the meaning
> > of error code.
>
> I think the text does that.