> From: [email protected] <[email protected]> On > Behalf Of Alvaro Karsz > > Should we have a vote? > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/158
I missed your previous response. Sorry for the late response. Why cannot device say as MUST requirement? Let say there is a device out that exposes a F_HASH_REPORT without F_CTRL_VQ. So driver tried to send a command and failed to issue cmd. End result, hash config was not successful. Did driver gain anything from seeing supplied hash in the config space? No. it just confused driver that device offered feature bit, could see the supposed hash, but still couldn't configure it. So, I think the right fix is that device MUST NOT set F_HASH_REPORT without F_CTRL_VQ. And driver should .. is fine, because existing driver that followed 1.2 will negotiate, and device will also accept it if it offered without F_CTRL_VQ. Any new device that follows 1.3 will not offer F_HAS_REPORT without C_VQ, hence it cannot be negotiated by driver without C_VQ. The gain is : device doesn't need to continue offering F_HASH_REPORT without C_VQ. And I doubt if any device would have done it, as it was obvious. Just the spec was missed out. Is MUST/SHOULD big deal here for device? At least not to me, from practical standpoint to me. Making must just makes the spec consistent with rest without breaking backward compat. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
