[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] QOM: best way for parents to pass informatio

From: Igor Mammedov
Subject: Re: [Qemu-arm] [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)
Date: Tue, 19 Jul 2016 15:29:30 +0200

On Tue, 19 Jul 2016 14:21:05 +0200
Paolo Bonzini <address@hidden> 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{} 

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 

> 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.  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]