From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPV5s-00049F-Cc for qemu-devel@nongnu.org; Tue, 19 Jul 2016 09:29:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPV5m-0003mo-M5 for qemu-devel@nongnu.org; Tue, 19 Jul 2016 09:29:51 -0400 Date: Tue, 19 Jul 2016 15:29:30 +0200 From: Igor Mammedov Message-ID: <20160719152930.597964c5@nial.brq.redhat.com> In-Reply-To: References: <20160615005620.GU4882@voom.fritz.box> <20160714200743.GC31865@thinpad.lan.raisama.net> <20160715063530.2ebl4v4vpdtrpx5a@hawk.localdomain> <20160715111138.114d8b5f@nial.brq.redhat.com> <20160715161009.GB3727@thinpad.lan.raisama.net> <20160715174353.GD3727@thinpad.lan.raisama.net> <20160715203835.38565299@igors-macbook-pro.local> <20160715213353.GA3618@thinpad.lan.raisama.net> <20160718092304.363ac0c0@nial.brq.redhat.com> <20160719115935.GB3337@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QOM: best way for parents to pass information to children? (was Re: [PATCH RFC 07/16] qom/cpu: make nr-cores, nr-threads real properties) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Eduardo Habkost , peter.maydell@linaro.org, Andrew Jones , qemu-devel@nongnu.org, agraf@suse.de, qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bharata B Rao , Thomas Huth , dgibson@redhat.com, Andreas =?UTF-8?B?RsOkcmJlcg==?= , David Gibson On Tue, 19 Jul 2016 14:21:05 +0200 Paolo Bonzini wrote: > On 19/07/2016 13:59, Eduardo Habkost wrote: > >>> > > If it's internal, do we have any reason to register a (writeable) > >>> > > property in the first place? Why not use a plain old > >>> > > "obj->field = value" C statement? Or, if a simple assignment > >>> > > isn't enough, why not a simple obj_set_field(value) C function? > >> > So that arch neutral code won't have to pull obj type definition > > > > I don't get it. If arch neutral code uses it, it should be > > available in an arch-neutral header. > > I agree. If arch-neutral code uses it, the method should be in CPUClass. it looks a bit like deQOMification, but if it's preferred we can do following for -smp. 1. Add machine::{nr_cores,nr_threads,nr_sockets} fields 2. Add to concrete cpus classes that use above data (as globals currently) a duplicate fields ex: X86CPU:{nr_cores,nr_threads} 3: Have X86CPU:{nr_cores,nr_threads} fields set buy PCMachine::pre_plug{} handler That way we'd have a bit of data duplication in X86CPU:{nr_cores,nr_threads} but still maintain role separation where CPUs won't have to to poke into its parent containers (machine). The sort of what we are doing currently with apic-id. > > Paolo > > >> > and we would be able to reuse all machinery that uses properties > >> > instead of inventing yet another API or ad-hoc function calls. > > Why is adding a new C function or setting a struct field worse > > than adding a new property name? I actually prefer the former, > > because it makes code review easier and allows the compiler to > > detect more mistakes.