From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SozUS-0005Dd-NZ for qemu-devel@nongnu.org; Wed, 11 Jul 2012 12:10:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SozUQ-0006iI-TG for qemu-devel@nongnu.org; Wed, 11 Jul 2012 12:10:12 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:59914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SozUQ-0006hq-K8 for qemu-devel@nongnu.org; Wed, 11 Jul 2012 12:10:10 -0400 Received: by pbbro12 with SMTP id ro12so2336753pbb.4 for ; Wed, 11 Jul 2012 09:10:08 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4FFDA559.6060309@redhat.com> Date: Wed, 11 Jul 2012 18:10:01 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1339772759-31004-1-git-send-email-pbonzini@redhat.com> <1339772759-31004-14-git-send-email-pbonzini@redhat.com> <4FDB75CF.6000004@redhat.com> In-Reply-To: <4FDB75CF.6000004@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 13/36] block: introduce block job error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com, lcapitulino@redhat.com Il 15/06/2012 19:50, Eric Blake ha scritto: >> > { 'type': 'BlockJobInfo', >> > 'data': {'type': 'str', 'device': 'str', 'len': 'int', >> > - 'offset': 'int', 'paused': 'bool', 'speed': 'int'} } >> > + 'offset': 'int', 'paused': 'bool', 'speed': 'int', >> > + 'io-status': 'BlockDeviceIoStatus'} } > Again, when adding members to output-only types compared to a previous > release, should we be marking the additions as optional, as in: > > '*io-status': 'BlockDeviceIoStatus' > > to indicate that the member may not be present when talking to older qemu? I don't think so, but still we should add it to the documentation. If in the future we will generate code that exports the types, these should not be indicated as optional IMHO. Optional is more like a JSON null value (in fact in Javascript a['nonexistent'] is null). Instead, we should add a new notation indicating that this could have a default value (false in the case of 'paused', 'ok' here), and the generated code would synthesize the default value if the JSON lacks the item. This could be used also in some commands. We mark some arguments as optional, but it would be easier to present them as having a default value. In particular, in a C API likely you would prefer to map such cases to one C arguments rather than a pair "has_foo"+"foo". Paolo