From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBQjQ-0007ck-Uh for qemu-devel@nongnu.org; Thu, 06 Feb 2014 10:19:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBQjL-0004pP-4t for qemu-devel@nongnu.org; Thu, 06 Feb 2014 10:19:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBQjK-0004pJ-T5 for qemu-devel@nongnu.org; Thu, 06 Feb 2014 10:19:07 -0500 Date: Thu, 6 Feb 2014 16:19:01 +0100 From: Igor Mammedov Message-ID: <20140206161901.14d44e55@nial.usersys.redhat.com> In-Reply-To: <20140205175216.3e011738@thinkpad> References: <1385591336-2755-1-git-send-email-imammedo@redhat.com> <52AE3247.5000303@suse.de> <20140205154007.4886f3e3@thinkpad> <52F26363.2050607@suse.de> <20140205175216.3e011738@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [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: Igor Mammedov Cc: Eduardo Habkost , qemu-devel@nongnu.org, armbru@redhat.com, Anthony Liguori , pbonzini@redhat.com, akong@redhat.com, Andreas =?ISO-8859-1?B?RuRyYmVy?= On Wed, 5 Feb 2014 17:52:16 +0100 Igor Mammedov wrote: > On Wed, 05 Feb 2014 17:14:27 +0100 > Andreas F=E4rber wrote: >=20 > > Am 05.02.2014 15:40, schrieb Igor Mammedov: > > > On Sun, 15 Dec 2013 23:50:47 +0100 > > > Andreas F=E4rber wrote: > > >=20 > > >> Am 27.11.2013 23:28, schrieb Igor Mammedov: > > >>> Igor Mammedov (16): > > >>> target-i386: cleanup 'foo' feature handling' > > >>> target-i386: cleanup 'foo=3Dval' feature handling > > >> > > >> Thanks, I've queued these on qom-cpu-next: > > >> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-next > > >> > > >>> target-i386: cpu: convert 'level' to static property > > >>> target-i386: cpu: convert 'xlevel' to static property > > >>> target-i386: cpu: convert 'family' to static property > > >>> target-i386: cpu: convert 'model' to static property > > >>> target-i386: cpu: convert 'stepping' to static property > > >>> target-i386: cpu: convert 'vendor' to static property > > >>> target-i386: cpu: convert 'model-id' to static property > > >>> target-i386: cpu: convert 'tsc-frequency' to static property > > >> > > >> But I still don't see the utility of this conversion after all the > > >> discussions we've had... :( > > > It seems there is movement to make DEVICE self describing for purpose > > > of QAPI schema introspection, where static properties would be used > > > (dynamic ones are not suitable for this purpose) > >=20 > > Do you have a pointer to such a discussion? Sounds like I was not > > involved and Anthony probably not either... > Not at the moment, CCing people who might know more about the topic. >=20 > But just thinking about creating QAPI schema for devices, it's not really > possible to generate one using dynamic properties (unless one resorts to > creating every supported device instance), while arrays of static propert= ies > are there for every device and simplistically speaking just need conversi= on > to schema format. There is one more reason to use static properties for external user-settable properties when it comes to device, i.e. to get list of properties user cou= ld use command: #qemu -device x86_64-cpu,? x86_64-cpu.pmu=3Dboolean x86_64-cpu.hv-spinlocks=3Dint x86_64-cpu.hv-relaxed=3Dboolean x86_64-cpu.hv-vapic=3Dboolean x86_64-cpu.check=3Dboolean x86_64-cpu.enforce=3Dboolean which now yields only partial properties user is interested in, above mentioned conversion patches make previously not available properties visible to user via typical interface, perhaps eventually we could drop list_cpu() interface in favor of -device foo-cpu,? command. Taking in account Paolo's cleanup of legacy properties in static properties, it might make them more suitable for moving concept to Object level. (As far as I remember, Anthony objected to it due to existence of legacy properties). =20 > >=20 > > Andreas > >=20 > > --=20 > > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg >=20 >=20