From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLxUj-0007Kq-CV for qemu-devel@nongnu.org; Thu, 03 Nov 2011 09:38:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLxUf-0007R3-4t for qemu-devel@nongnu.org; Thu, 03 Nov 2011 09:38:13 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:60953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLxUe-0007Qz-VT for qemu-devel@nongnu.org; Thu, 03 Nov 2011 09:38:09 -0400 Received: by qadc12 with SMTP id c12so1326992qad.4 for ; Thu, 03 Nov 2011 06:38:08 -0700 (PDT) Message-ID: <4EB2993C.9000902@codemonkey.ws> Date: Thu, 03 Nov 2011 08:38:04 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1317360376-12090-1-git-send-email-david@gibson.dropbear.id.au> <4EB07096.4070806@us.ibm.com> <4EB26EA5.4060606@redhat.com> <4EB291F4.8070503@us.ibm.com> <4EB29381.9060707@redhat.com> In-Reply-To: <4EB29381.9060707@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, David Gibson 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. >