[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost <ehabkost 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 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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]