qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO B


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR
Date: Thu, 03 Nov 2011 15:13:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

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
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)
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.

-- 
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]