virtio — archive

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

On Wed, Feb 15, 2023 at 04:46:26AM +0000, Parav Pandit wrote: > > > 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. If it is relevant somehow, bring it in. > > > 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. Yea that makes sense. -- MST