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(a)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(a)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