Re: [virtio] [PATCH 4/5] packed-ring: reposition drivernormative on driver notifications

[Halil Pasic <pasic@linux.ibm.com>]

On 04/20/2018 05:59 PM, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2018 at 04:59:12PM +0200, Halil Pasic wrote:
> > My concern (regarding the whole spec) is the completeness and self
> > the containment of it's normative portion -- I'm not sure if either is
> > pursued rigorously.
>
> No it isn't, and the reason is we do not want to bring the development
> to a complete halt :). Our charter is
>
> 	Enhancing the performance of virtual devices by standardizing key
> 	features of the VIRTIO (Virtual I/O) Device Specification
>
> Our job is thus to facilitate development by standardizing where it's
> helpful.
>
> If we start asking people to write out a formal spec for any tiny
> change before they can release code, development will stop and
> performance will suffer.
>
> And it's a balance: it should be clear what is going on,
> and if people can write it rigorously without confusing
> matters, it is helpful.
>
> But we don't want something like e.g. the C or C++ language spec,
> where you can read all of it and still have no idea how to use it.

I understand.

> > For instance take 'Supplying Buffers to The
> > Device' either for split or for packed. The algorithms described
> > there aren't constituting a normative section. Do you think these
> > can be inferred from the normative sections?
>
> No but it's ok for normative sections to refer to the non-normative
> ones.

Was, kind of, the point I tried to make. I've (for myself) given up on
these ideals. That's why I did not bother to think about isn't that sentence
normative section material. And I don't intend to clean up normative
vs non-normative.

Anyway, it is good to have it spelled out what is the objective of this document,
and what is not. I will continue to try to improve the specification,
in accordance to that -- and avoid hanging myself up on what is not
considered a primary objective.

Many thanks!

Regards,
Halil