From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUGMW-0003so-4j for qemu-devel@nongnu.org; Mon, 22 Apr 2013 09:00:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUGMR-0001kB-28 for qemu-devel@nongnu.org; Mon, 22 Apr 2013 09:00:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUGMQ-0001ji-FQ for qemu-devel@nongnu.org; Mon, 22 Apr 2013 09:00:46 -0400 Message-ID: <51753471.5080803@redhat.com> Date: Mon, 22 Apr 2013 15:00:33 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1366275680-15416-1-git-send-email-kraxel@redhat.com> <87ppxq6hmn.fsf@blackfin.pond.sub.org> <5174DEE5.20406@redhat.com> <517504CB.6040303@redhat.com> <20130422085043.4a3e891c@redhat.com> In-Reply-To: <20130422085043.4a3e891c@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org, aliguori@us.ibm.com, Gerd Hoffmann , Markus Armbruster Il 22/04/2013 14:50, Luiz Capitulino ha scritto: > On Mon, 22 Apr 2013 11:37:15 +0200 > Paolo Bonzini wrote: > >> Il 22/04/2013 08:55, Gerd Hoffmann ha scritto: >>>>>>> Question for the libvirt guys: Is it ok for libvirt to just extend the >>>>>>> existing screendump command? Can libvirt figure there is a new >>>>>>> (optional) parameter? See patch #5. >>>>> >>>>> Nope, QMP can't do that. I argued for such capabilities, but the >>>>> "create a new command" philosophy prevailed. >>>>> >>>>> Go forth and multiply commands! And have fun picking command names that >>>>> aren't fugly. >>> Oh joy. Lets just enumerate things & use "screendump2" ... >> >> QMP can't do that _yet_. >> >> Let's fix it instead... > > The point is that we have chosen not to do so a while ago. In a nutshell, > Anthony thinks that we should have the same compatibility contract of > a C API. We've been adding fields to types since 0.15, sometimes in the middle of a struct (since 1.2). If the C API is a requirement, it should also be a requirement for structs. But there are plenty of ways (some nicer, some uglier) to have different API versions in C. For example, I think the QIDL patch had ways to annotate each parameter independently. You can annotate each argument with the "first version this appeared in" and complicate the C API generator to generate multiple C functions for the same command. It is then the downstream's responsibility not to backport extra arguments without a full-blown rebase to a newer version (the same as for C libraries). Paolo