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)

[Paolo Bonzini]

On 19/07/2016 15:29, Igor Mammedov wrote:
> 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.

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