From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9ih9-0003iq-QS for qemu-devel@nongnu.org; Mon, 19 Mar 2012 15:56:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9igx-0007q6-Ad for qemu-devel@nongnu.org; Mon, 19 Mar 2012 15:56:43 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:44912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9igx-0007pq-6m for qemu-devel@nongnu.org; Mon, 19 Mar 2012 15:56:31 -0400 Received: by ghrr14 with SMTP id r14so6757199ghr.4 for ; Mon, 19 Mar 2012 12:56:29 -0700 (PDT) Message-ID: <4F678F6A.3050804@codemonkey.ws> Date: Mon, 19 Mar 2012 14:56:26 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1332185368-18708-1-git-send-email-pbonzini@redhat.com> <4F678A37.1020101@codemonkey.ws> <4F678E38.7050902@redhat.com> In-Reply-To: <4F678E38.7050902@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC/RFA PATCH] qapi: detect extra members inside structs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Michael Roth , qemu-devel@nongnu.org, lcapitulino@redhat.com On 03/19/2012 02:51 PM, Paolo Bonzini wrote: > Il 19/03/2012 20:34, Anthony Liguori ha scritto: >>> >>> Is this acceptable or just wrong? >> >> This is a feature. The idea is that with QMP, old clients just ignore >> extra members in a structure. I've never felt that comfortable with >> this as a semantic but this is how QMP was designed. > > For old clients that could be fine. But what about old servers? :) Same applies to old server. If a new client tries to use a new field, if the old server refuses it, then the new client breaks. There's no way in QMP to detect whether a server supports a new field. This is why I proposed instituting a policy of never adding/removing fields to structures and why I had advocating use a C version of libqapi in terms of enforcing compatibility rules. I'm not sure if the "server ignores unknown" fields thing is even reasonable to rely upon so maybe we should just draw a line in the sane and make the change you're suggesting... Regards, Anthony Liguori > > Perhaps we need an argument to the QMPInputVisitor constructor to > control this. > >> If you don't allow this semantic, then it's impossible to ever add a >> field to an existing type as that would break backwards compatibility. > > Paolo