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

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Feb 13, 2023 at 02:13:43PM +0100, 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.

In fact I think it is a good idea to
1. actually link to where one can see EINVAL=22 so people know where to find
   more values
2. ask driver to handle any other error same as EINVAL for now - we don't want
   new feature bits if all we do down the road is add more error codes.

I'll add this in the next version.

-- 
MST