Re: [Qemu-ppc] [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)

[Igor Mammedov]

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