On 11/03/2011 08:13 AM, Avi Kivity wrote:
On 11/03/2011 03:07 PM, Anthony Liguori wrote:
On 11/03/2011 05:36 AM, Avi Kivity wrote:
On 11/02/2011 12:20 AM, Anthony Liguori wrote:
Seems harmless for QEMU, so applied. You should update the virtio-pci
spec too.
Should be the other way round.
Am not entirely sure. Having worked code that's been reviewed will
make for a better spec. Writing the spec and committing to the spec
change before getting either side of the implementation merged seems
to be asking for trouble to me.
Maybe. But committed code before a spec proposal?
I can see the spec maintainer requiring prototype code (for both guest
and host). But committing code before a spec change is even seen is not
the right way to do this.
We could use a better agreement on the processor for making virtio
changes. Should it go (1) virtio spec (2) kernel (3) qemu, or should
it go (2), (1), (3)?
1. Informal discussion
Where? Is this lkml? There were a number of virtio changes recently that never
involved qemu-devel.
2. Proposed spec patch, kernel change, qemu change
3. Buy-ins from spec maintainer, kernel driver maintainer, qemu device
maintainer (only regarding the ABI, not the code)
I don't think this is how it's working today. I would be happy with a flow like
this.
Regards,
Anthony Liguori
4. Spec change committed
5. kernel and qemu code submitted and committed through the normal process
Note there are multiple implementations of the device code (qemu virtio,
linux vhost) and driver code (linux, windows). The only real
synchronization point is the spec.