From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 2B3C0986566 for ; Tue, 14 Feb 2023 09:01:06 +0000 (UTC) From: Cornelia Huck In-Reply-To: <20230213152739-mutt-send-email-mst@kernel.org> References: <20230209121221.15118-1-mst@redhat.com> <20230209121221.15118-4-mst@redhat.com> <20230212044245-mutt-send-email-mst@kernel.org> <20230213031358-mutt-send-email-mst@kernel.org> <878rh1d9dz.fsf@redhat.com> <680c32ee-5dac-ab20-981a-bec134ca33c8@nvidia.com> <87wn4lbtdk.fsf@redhat.com> <20230213152739-mutt-send-email-mst@kernel.org> Date: Tue, 14 Feb 2023 10:01:01 +0100 Message-ID: <87k00kd3jm.fsf@redhat.com> MIME-Version: 1.0 Subject: [virtio-comment] Re: [virtio] Re: [virtio-comment] Re: [PATCH v10 03/10] admin: introduce group administration commands Content-Type: text/plain To: "Michael S. Tsirkin" Cc: Max Gurtovoy , Parav Pandit , "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" , "jasowang@redhat.com" , "sgarzare@redhat.com" , "stefanha@redhat.com" , "nrupal.jani@intel.com" , "Piotr.Uminski@intel.com" , "hang.yuan@intel.com" , "virtio@lists.oasis-open.org" , Zhu Lingshan , "pasic@linux.ibm.com" , Shahaf Shuler List-ID: On Mon, Feb 13 2023, "Michael S. Tsirkin" wrote: > On Mon, Feb 13, 2023 at 02:13:43PM +0100, Cornelia Huck wrote: >> On Mon, Feb 13 2023, Max Gurtovoy wrote: >> >> > On 13/02/2023 14:42, Cornelia Huck wrote: >> >> 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 >> >> >> > >> > 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. Wfm. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/