From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPU1Y-0000Sl-QR for qemu-devel@nongnu.org; Tue, 19 Jul 2016 08:21:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPU1W-0004P6-MZ for qemu-devel@nongnu.org; Tue, 19 Jul 2016 08:21:19 -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> From: Paolo Bonzini Message-ID: Date: Tue, 19 Jul 2016 14:21:05 +0200 MIME-Version: 1.0 In-Reply-To: <20160719115935.GB3337@thinpad.lan.raisama.net> 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: Eduardo Habkost , Igor Mammedov Cc: 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 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. 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.