On 19/07/2016 15:29, Igor Mammedov wrote:
> On Tue, 19 Jul 2016 14:21:05 +0200
> Paolo Bonzini <pbonz...@redhat.com> 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.
>
