From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPVG2-0002MT-LC for qemu-devel@nongnu.org; Tue, 19 Jul 2016 09:40:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPVFw-0007lL-VW for qemu-devel@nongnu.org; Tue, 19 Jul 2016 09:40:21 -0400 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> <20160719152930.597964c5@nial.brq.redhat.com> From: Paolo Bonzini Message-ID: <8f916f68-2af7-6af5-66b1-e9fe4d19dfe6@redhat.com> Date: Tue, 19 Jul 2016 15:39:59 +0200 MIME-Version: 1.0 In-Reply-To: <20160719152930.597964c5@nial.brq.redhat.com> Content-Type: text/plain; charset=windows-1252 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: Igor Mammedov 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, =?UTF-8?Q?Andreas_F=c3=a4rber?= , David Gibson On 19/07/2016 15:29, Igor Mammedov wrote: > 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. Properties are primarily an interface for users. Sometimes we use them internally when they are anyway inaccessible to users, but if you want to hide things from users there's already a suitable mechanism which is class and interface methods. Paolo > 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. >