From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33185 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLe5r-00046K-Se for qemu-devel@nongnu.org; Mon, 07 Jun 2010 11:18:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLe5p-00038z-HZ for qemu-devel@nongnu.org; Mon, 07 Jun 2010 11:18:26 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:45248) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLe5p-00038r-Ek for qemu-devel@nongnu.org; Mon, 07 Jun 2010 11:18:25 -0400 Received: by iwn41 with SMTP id 41so3603065iwn.4 for ; Mon, 07 Jun 2010 08:18:24 -0700 (PDT) Message-ID: <4C0D0DB6.3020407@codemonkey.ws> Date: Mon, 07 Jun 2010 10:18:14 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities References: <1275921752-29420-1-git-send-email-berrange@redhat.com> <4C0D0903.50207@codemonkey.ws> <20100607151016.GC27291@redhat.com> In-Reply-To: <20100607151016.GC27291@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org On 06/07/2010 10:10 AM, Daniel P. Berrange wrote: > On Mon, Jun 07, 2010 at 09:58:11AM -0500, Anthony Liguori wrote: > >> On 06/07/2010 09:42 AM, Daniel P. Berrange wrote: >> >>> As everyone here agrees, having management apps parse -help output >>> to determine the QEMU capabilities is not at all nice, because it >>> is an ill-defined& fragile data format. Looking more broadly these >>> same issues apply to all the other command line options that accept >>> a '?' flag for querying capabilities. >>> >>> We have a very nice structured data format we could be using for >>> this: JSON. What's lacking is code to output all this information >>> in the JSON format. This patch series can thus be summarized as >>> 'JSON for everything' >>> >>> >> I'm slightly skeptical that JSON is the right format for this TBH. >> >> >>> For reference, here is the full list of information libvirt currently >>> queries from QEMU: >>> >>> * Detection of command line flags (-help parsing) >>> >>> -no-kqemu, -no-kvm, -enable-kvm, -no-reboot >>> -name, -uuid, -xen-domid, -domid, -drive >>> -vga, -std-vga, -pcidevice, -mem-path >>> -chardev, -balloon, -device, -rtc, -rtc-td-hack >>> -no-hpet, -no-kvm-pit-reinjection, -tdf >>> -fsdev -sdl >>> >>> >> Most of these things can be associated with a config option and/or a >> version. >> > If the 'qemu-config.c' file had parity with the config options > that were available as argv then I would not suggest including > the argv data at all. I meant config-*.h. I can certainly imagine an query-config command to return a builtin copy of the build configuration. If you know the qemu configuration along with the version, you basically know everything you need to know about the supported options (beyond what is configurable by the user). Regards, Anthony Liguori > This patchset is an attempt to provide > all the information we need based on current state of the QEMU > codebase, since qemu-config is seriously incomplete at this time. > If we instead want to make a concerted effort to finish porting > all existing config options over to the new style qemu-config.c > format, that would definitely be much nicer than reporting about > argv. > > Regards, > Daniel >