From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR
Date: Thu, 03 Nov 2011 15:13:37 +0200 [thread overview]
Message-ID: <4EB29381.9060707@redhat.com> (raw)
In-Reply-To: <4EB291F4.8070503@us.ibm.com>
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
next prev parent reply other threads:[~2011-11-03 13:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 5:26 [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR David Gibson
2011-11-01 22:20 ` Anthony Liguori
2011-11-02 0:16 ` David Gibson
2011-11-02 0:32 ` Anthony Liguori
2011-11-02 3:22 ` Rusty Russell
2011-11-02 12:39 ` Anthony Liguori
2011-11-02 21:51 ` Michael S. Tsirkin
2011-11-03 10:36 ` Avi Kivity
2011-11-03 13:07 ` Anthony Liguori
2011-11-03 13:13 ` Avi Kivity [this message]
2011-11-03 13:38 ` Anthony Liguori
2011-11-03 13:45 ` Avi Kivity
2011-11-03 13:49 ` Anthony Liguori
2011-11-03 14:31 ` Michael S. Tsirkin
2011-11-03 14:37 ` Anthony Liguori
2011-11-03 14:53 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EB29381.9060707@redhat.com \
--to=avi@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).