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&gt; 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&gt; 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