From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMIie-0004wc-3O for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:22:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMIiX-0006jL-PP for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:22:32 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:48453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMIiX-0006jE-J1 for qemu-devel@nongnu.org; Thu, 11 Oct 2012 09:22:25 -0400 Received: by mail-pa0-f45.google.com with SMTP id fb10so1724916pad.4 for ; Thu, 11 Oct 2012 06:22:24 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5076C803.6040601@redhat.com> Date: Thu, 11 Oct 2012 15:22:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1349877786-23514-1-git-send-email-pbonzini@redhat.com> <1349877786-23514-25-git-send-email-pbonzini@redhat.com> <5075DD61.6060501@redhat.com> <5076C460.8020704@redhat.com> <5076C64C.1050303@redhat.com> In-Reply-To: <5076C64C.1050303@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 24/25] qmp: add NBD server commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, lcapitulino@redhat.com Il 11/10/2012 15:14, Eric Blake ha scritto: >>>> +## >>>> +# @nbd-server-add: >>>> +# >>>> +# Export a device to QEMU's embedded NBD server. >>>> +# >>>> +# @device: Block device to be exported >>>> +# >>>> +# @writable: Whether clients should be able to write to the device via the >>>> +# NBD connection (default false). #optional >>> >>> Isn't the #optional designation supposed to come first, before 'Whether'? >> >> Does it really matter with no program yet written to consume it? >> Putting it at the end matches the old qmp-commands.hx format better (for >> commands that do have qmp-commands.hx documentation). > > I'm just asking on the grounds of consistency based on observation, and > not based on an actual hard requirement of something that goes wrong if > it's out of order. Therefore, I'm okay with your explanation, as long > as no one else can provide hard evidence for a mandatory positioning of > the marker. In fact, if such a program existed, it would be able to derive the optional-ness of the argument from the schema, and it would make sense for consistency to eliminate all #optional markers... Paolo