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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 19/03/2012 17:41, Anthony Liguori ha scritto:
> On 03/19/2012 11:33 AM, Paolo Bonzini wrote:
>> Il 19/03/2012 17:31, Anthony Liguori ha scritto:
>>>>> 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?
>>
>> Right, sorry.  Into configuration file ABI, which is supposed to be the
>> "cleaner" ABI.
> 
> Right, the basic premise of this series is "perfect is the enemy of
> good".  I think we do ourselves more harm than good trying to come up
> with a clean new interface instead of just cleaning up the bits behind
> what we previously had.

Yeah,it depends on what you consider good. :)  My direction was like
"let's cover 90% of the usecases with a decent syntax"; yours is "let's
cover 100% of the usecases even though the syntax may stink".

(There's time to convert -display before 1.1, which would make 99%).

>>>> 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?
>>
>> If you write "-monitor stdio" with your series, do you get one or two
>> monitors in the resulting configuration file?
> 
> Two, I now understand what you're saying.  Let me look into fixing
> that.  This is more about -writeconfig.  We need to record the origin of
> a particular QemuOpt and have -writeconfig spit out only things that
> came from -readconfig.

I think it's simpler than that.  Just don't mark as gdef those options
that are backed internally by QemuOpts.

Paolo