Should the TC defer resolve issue VIRTIO-176, to after 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-176: Many device and driver in-memory structure layouts...
--------------------------------------
1.4 Structure Specifications begins with: "Many device and driver in-memory structure layouts are documented using the C struct syntax."
Many? Not all? Many leave it doubtful that some are defined.
Why not: "Device and driver in-memory structure layouts are documented using the C struct syntax."
If you are missing any, add them.
--------------------------------------
The TC agrees that the issue will not be resolved for the revision
"virtio-v1.1-cs01" of the specification.
Justification:
--------------------------------------
Legacy layouts are documented using tables. Rewriting them would be a
hard mostly thankless task. Single field structures also use
e.g. le64 directly.
--------------------------------------
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.
--------------------------------------
|