Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Anthony Liguori <anthony@codemonkey.ws>]

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
>