On Mon, Feb 13 2023, Max Gurtovoy <mgurto...@nvidia.com> wrote: > On 13/02/2023 15:13, Cornelia Huck wrote: >> On Mon, Feb 13 2023, Max Gurtovoy <mgurto...@nvidia.com> wrote: >> >>> On 13/02/2023 14:42, Cornelia Huck wrote: >>>> On Mon, Feb 13 2023, Max Gurtovoy <mgurto...@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. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
