Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/19/2012 11:09 AM, Paolo Bonzini wrote:
> Il 19/03/2012 16:09, Anthony Liguori ha scritto:
>> Hi,
>>
>> I didn't start out intending to write this series, but I end up here trying to
>> resolve an issue in the gtk UI.
>
> What issue? :)

I rewrote the scaling support and did some usability testing with my 
unsuspecting wife...  To make a long story short, my take away was that I need a 
way to have persistent configuration options.  That got me looking at 
readconfig/writeconfig.

>
>> This series does some dramatic refactoring to -readconfig essentially throwing
>> away the existing (trivial) implementation and replacing it with glib's
>> GKeyFile support.
>
> Nice.
>
>> It also plumbs the existing command line options through QemuOpts via a special
>> 'system' section.  This means that any command line option can be specified via
>> readconfig and that the combination of -nodefconfig and -writeconfig should give
>> you exactly the same guest in a repeatable fashion.
>
> I don't like this because it turns command-line options into ABI.

It's already an ABI, no?

> Also,
> it puts there some options for which -writeconfig is actually able to
> produce a QemuOpts equivalent, such as -monitor.

That may be a bug depending on what your concern is.  Can you be more specific?

> I have a few patches here that convert almost every option that matters
> into QemuOpts so that -writeconfig records it: -m, -bios, -localtime,
> -S, -M, -smp, -numa, -nodefaults, -no-shutdown, -no-reboot.  The only
> thing that is left basically is -display, where I chickened out.

This series is complimentary to this.  You can still promote options to 
QemuOpts.  The advantage of this series is that we provide a programmatic way 
for libvirt to discover when this happens.

If you look at the management guide that I included, I made a strong statement 
that we promise to never extend existing options without first converting to 
QemuOpts.

>
>> Finally, this series exposes a new -query-capabilities option which dumps the
>> QemuOpts schema's via JSON to standard output (along with some other goodies
>> like the version info and supported QMP commands).
>>
>> The purpose of this series is to change the way management tools (esp libvirt)
>> interact with QEMU to determine capabilities.  Instead of help parsing, libvirt
>> should use -query-capabilities to figure out which options are supported and
>> when new suboptions are available.
>>
>> I would like to push this series into 1.1
>
> I think it's too early.  However, we can definitely apply 1/2/7/8/9 now.

Let's go through the discussion and see where we end up.  I was just stating my 
intentions so that folks reviewed appropriately.

But I realize there's a lot of discussion that needs to happen before we make 
this type of commitment for 1.1.

Regards,

Anthony Liguori

>
> Paolo
>