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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, February 14, 2023 4:58 PM

> > > > 1. If we start putting 22 with Linux annotations, in few weeks
> > > > virtio Net device
> > > section will be full of annotation of ethtool, tc, ip config and
> > > more for Linux developers.
> > > > For example, the current two interrupt moderation patches need to
> > > > write
> > > ethtool options details to match to following this Linux example here.
> > This cannot be relaxed if errno.h and Linux annotation must be added.
> 
> I dont really know what does this mean.
>
It means why should Linux annotation is limited to error codes of AQ.
Why not annotate Linux for other areas of the spec such as ethtool annotation for interrupt moderation.
 
> > And I don't think its correct direction for the spec.
> >
> > > > It is better to avoid such things and keep spec OS agnostics, even
> > > > though it is
> > > addressing and fitting into the Linux use cases.
> > > >
> > > > 2. Virtio error code to Linux error code switch-case is simple routine to
> have.
> > > >
> > > > 3. Every time virtio spec to refer to errno.h for finding right
> > > > value is opposite
> > > of what spec may want to achieve.
> > > > If an error code doesn't match to errno.h, now spec developers and
> > > > reviewers
> > > to review what is not defined by errno.h to find as unique value.
> > > >
> > > > 3.1 And if that is taken in future by errno.h for something else?
> > > >
> > > > All of this is not worth a simple switch case statement to deal with.
> > >
> > > I think we'll have to agree to disagree here. Years working on virt
> > > taught me that matching some existing interface is usually better
> > > than coming up with our own.
> > With all due respect to your working experience on virt, learning from existing
> technology, standards, and open-source software is certainly good.
> 
> Glad we agree on this...
> 
> > However, it is a not correct to imply that virtio community will make mistake if
> they do not copy error codes from the errno.h file for AQ.
> 
> unfortunately you seem not to follow this to the logical conclusion.
> 
> > > Even if it is a bit more work upfront it pays dividends later.

> > If virtio is copying GPLv2 errno.h error codes, it must be spelled out in
> licensing area and generic line as errno.h and not just "Linux".
> > I don't think this is right for virtio spec.
> 
> Neither EINVAL nor the value 22 are under GPL in any way.
>
I referred to [1] https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/errno-base.h#L26
And missed the sycall note at start.
Thanks for the clarification.

> 
> > > And yes we can come up with crazy conventions like 0xdead for success.
> > > Does not mean we should.
> > The question is: Can virtio community define error codes by learning from
> errno.h, netlink errors and by learning from other industry leading specs?
> > I think yes, community members in this email thread can do that without
> annotating Linux in the spec.
> >
> > My humble request is, let's spend more time to solidify the AQ on other
> aspects than copying error codes.
> 
> Yea I have no idea why you are wasting your and my time on this either.
> Repeating the same thing over and over will not make it right. And no we do not
> need more arguments either.

Not sure what was repeated...

Anyways, if you have so strong preference to use the derivative work of "Linux", 
please add the stable link of it the section 1.1 or 1.2 references sections and refer to it in the text.
This will make things crystal clear for the source of existing and future error codes.