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

[Andreas Färber]

Am 11.02.2014 16:58, schrieb Anthony Liguori:
> On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost <address@hidden> 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 <address@hidden> 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.

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