Should the TC defer addressing the issue VIRTIO-169, for specification version(s) "virtio-v1.1-cs01"?
Please vote Yes if you agree with all of the following.
If you disagree, please vote No.
If you don't have an opinion, please vote Abstain.
I move that:
The TC agrees to defer resolving the following specification issue:
VIRTIO-169: device and driver in-memory structure layouts - label and number
--------------------------------------
While I appreciate that the use of C struct syntax is illustrative only, the in-memory structures it documents are normative.
And in a number of cases, those in-memory structures occur in the same numbered section, making reference to any specified in-memory structure uncertain.
Labeling and numbering the in-memory structures (to say nothing of adding anchors for remote pointing), would greatly improve the usefulness of this document.
--------------------------------------
The TC agrees that the issue will not be resolved for the revision
"virtio-v1.1-cs01" of the specification.
Justification:
--------------------------------------
I can't see a way to label them without messing up formatting. That's not too
bad I think, since they're explicitly inline with surrounding text.
the issue is not new - it appears in virtio-v1.0-cs04 too.
And a similar issue was raised wrt tables:
https://issues.oasis-open.org/browse/VIRTIO-66
--------------------------------------
--------------------------------------
Reminder: A Voting Member must be active in a TC to maintain voting rights. As
the Virtio TC has adopted a standing rule to conduct business only by
electronic ballot, without Meetings, a Voting Member who fails to cast a ballot
in two consecutive Work Product Ballots loses his or her voting rights at the
close of the second ballot missed.
--------------------------------------
|