From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDIWW-0004r9-Eo for qemu-devel@nongnu.org; Tue, 11 Feb 2014 13:57:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDIWO-0001hx-0X for qemu-devel@nongnu.org; Tue, 11 Feb 2014 13:57:36 -0500 Received: from mail-qa0-f41.google.com ([209.85.216.41]:48784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDIWN-0001hm-RE for qemu-devel@nongnu.org; Tue, 11 Feb 2014 13:57:27 -0500 Received: by mail-qa0-f41.google.com with SMTP id w8so12413246qac.28 for ; Tue, 11 Feb 2014 10:57:27 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <52FA5605.7040305@suse.de> References: <20140205154007.4886f3e3@thinkpad> <52F26363.2050607@suse.de> <20140205175216.3e011738@thinkpad> <20140206161901.14d44e55@nial.usersys.redhat.com> <52F3AF75.90106@suse.de> <20140206161627.GE28427@otherpad.lan.raisama.net> <52F3BF02.3070804@suse.de> <20140207101609.GF28427@otherpad.lan.raisama.net> <52F4BB9D.60301@redhat.com> <20140211152544.GA24353@otherpad.lan.raisama.net> <52FA5605.7040305@suse.de> Date: Tue, 11 Feb 2014 10:57:27 -0800 Message-ID: From: Anthony Liguori Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] CPU models and feature probing (was Re: [PATCH qom-cpu 00/16 v10] target-i386: convert CPU) features into properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Eduardo Habkost , libvir-list@redhat.com, qemu-devel , Markus Armbruster , Anthony Liguori , Igor Mammedov , Paolo Bonzini , Jiri Denemark , Amos Kong On Tue, Feb 11, 2014 at 8:55 AM, Andreas F=E4rber wrote: > Am 11.02.2014 16:58, schrieb Anthony Liguori: >> On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost w= rote: >>> On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote: >>>> On Fri, Feb 7, 2014 at 2:55 AM, Paolo Bonzini wr= ote: >>>>> Il 07/02/2014 11:16, Eduardo Habkost ha scritto: >>>>> >>>>>> You are not alone. I remember we spent lots of time trying to convin= ce >>>>>> 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 th= e >>> 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=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg