From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJkzo-0006a6-Dq for qemu-devel@nongnu.org; Thu, 04 Oct 2012 08:57:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJkzj-0006m7-NM for qemu-devel@nongnu.org; Thu, 04 Oct 2012 08:57:44 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35100 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJkzj-0006lu-Do for qemu-devel@nongnu.org; Thu, 04 Oct 2012 08:57:39 -0400 Message-ID: <506D87B9.7030803@suse.de> Date: Thu, 04 Oct 2012 14:57:29 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1349192235-31895-8-git-send-email-imammedo@redhat.com> <20121002203845.GB4362@otherpad.lan.raisama.net> <20121003150339.GS15784@otherpad.lan.raisama.net> <506C57CE.9060002@redhat.com> <20121003182411.7075c0ef@nial.usersys.redhat.com> <20121003165434.GT15784@otherpad.lan.raisama.net> <20121004085322.599a19ab@nial.usersys.redhat.com> <20121004124341.GU15784@otherpad.lan.raisama.net> In-Reply-To: <20121004124341.GU15784@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 07/23] target-i386: convert cpuid features into properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: aliguori@us.ibm.com, akong@redhat.com, stefanha@linux.vnet.ibm.com, gleb@redhat.com, jan.kiszka@siemens.com, Don@cloudswitch.com, mtosatti@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, avi@redhat.com, Paolo Bonzini , Igor Mammedov , hpa@linux.intel.com, lersek@redhat.com Am 04.10.2012 14:43, schrieb Eduardo Habkost: > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote: >> For x86 CPU classes we were going dynamically generate CPU classes and= store >> pointer to appropriate cpudef from builtin_x86_defs in class field for= each >> CPU class and then init default feature words values from this field i= nt >> x86_cpu_initfn(). >> >> However with qdev_prop_set_globals() in device_initfn() that is called= before >> x86_cpu_initfn() it won't work because defaults in x86_cpu_initfn() wi= ll >> overwrite whatever was set by qdev_prop_set_globals(). >=20 > We can set the default values on class_init, instead. The class_init > function for each CPU model can get the x86_def_t struct as the data > pointer. Let's avoid going backwards here, the plan was to have imperative initfns, so x86_def_t would go away, no? I'm catching up my mail on multiple fronts and will continue review, IIUC Blue already applied the CPU feature deduplification series so according to your roadmap this series is next. >> IMHO from general POV it's not correct to set properties before object= is >> completely created. >=20 > If I understood it correctly, the point of all this is to allow > properties (and their defaults) to be introspected by just looking at > the class, without having to create any object. It would be news to me that that was Anthony's plan... Static properties are being assigned to the class but populated at instantiation time. We do not have class properties as such. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg