[libvirt] [Qemu-devel] CPU models and feature probing (was Re: [PATCH qom-cpu 00/16 v10] target-i386: convert CPU) features into properties

[Anthony Liguori]

On Tue, Feb 11, 2014 at 8:55 AM, Andreas Färber <afaerber at suse.de> wrote:
> Am 11.02.2014 16:58, schrieb Anthony Liguori:
>> On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost <ehabkost at redhat.com> wrote:
>>> On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote:
>>>> On Fri, Feb 7, 2014 at 2:55 AM, Paolo Bonzini <pbonzini at redhat.com> wrote:
>>>>> Il 07/02/2014 11:16, Eduardo Habkost ha scritto:
>>>>>
>>>>>> You are not alone. I remember we spent lots of time trying to convince
>>>>>> Anthony to allow global properties and compat_props affect dynamic
>>>>>> properties not just static properties, and static properties were a big
>>>>>> deal due to reasons I didn't understand completely. Now I am hearing the
>>>>>> opposite message, and I don't understand the reasons for the change of
>>>>>> plans. I am confused.
>>>>>
>>>>>
>>>>> Picture me confused as well, but at the same I think I understand the
>>>>> reasons for the change of plans.
>>>>
>>>> There's no real convincing.  It's just a question of code.
>>>
>>> I am sure there's a lot of convincing involved, even after the code is
>>> written (in this case, 15 months after the code was written).
>>
>> N.B. the code you refer to doesn't "make global propeties and
>> compat_props affect dynamic properties."  It converts CPU properties
>> to static properties which I'm pretty sure I said many times is a
>> perfectly reasonable thing to do.
>>
>>>> There are
>>>> no defaults in classes for dynamic properties to modify.  compat_props
>>>> are a nice mechanism, making them work for all properties is a
>>>> reasonable thing to do.
>>>
>>> That's exactly the opposite of what you said before[1]. But that isn't
>>> supposed to be a problem, I understand there may be change of plans (we
>>> should be able to change our minds).
>>
>> I think you're confusing a few things.  You cannot make dynamic
>> properties work with globals today.  Globals change class default
>> values and there are no class defaults for dynamic properties.[*]
>>
>> There's a perfectly valid discussion to have about whether we should
>> even have dynamic properties.  It's certainly been a long time since
>> they were introduced and they haven't made their way into all that
>> many devices so it's reasonable to say that perhaps we'd be better off
>> without them.  I would not object to a patch series that moved
>> properties to classes entirely provided it removed existing uses of
>> dynamic properties and didn't just introduce yet another mechanism.
>>
>> But compat properties as a concept could be made to work with dynamic
>> properties.  They would have to be evaluated after instance init.
>> There's quite a few places they would end up touching I suspect.
>
> Erm, sorry, that is already implemented in qemu.git!? instance_post_init
> by Eduardo plus glue by me.

Ah, even better then :-)

Regards,

Anthony Liguori

> Andreas
>
>>
>> Another point of confusion worth mention is legacy properties since
>> this usually comes up in the discussion.  Legacy properties (the
>> properties that are set/get as strings) are something that we should
>> try to avoid.  They end up as strings on the wire and make it harder
>> to write client code.
>>
>> * I recognize that compat_props are implemented as globals.  I'm
>> really talking about the current implementation of globals, not the
>> concept of -global which could be made with dynamic properties.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> What I don't understand is the rejection of code that works, matches the
>>> style used by 200+ other source files, adds more useful introspectable
>>> information, done in the way that was suggested 16 months ago, because
>>> we have some rough idea about how a new grand design will look like in
>>> the far future.
>>>
>>> [1] http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg00990.html
>>>
>>> --
>>> Eduardo
>
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg