On Tue, Feb 11, 2014 at 8:55 AM, Andreas Färber <afaerber@suse.de> wrote:
Am 11.02.2014 16:58, schrieb Anthony Liguori:
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.
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