[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes |
Date: |
Mon, 19 Mar 2012 17:45:39 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 |
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
Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes, Eduardo Habkost, 2012/03/20