On 18 October 2016 at 19:45, Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Tue, Oct 18, 2016 at 07:12:51PM +0100, Peter Maydell wrote:
>> We actually have a concrete instance in the tree at the moment:
>> the raspberry pi 2. Specifically hw/arm/bcm2836.c sets the
>> mp_affinity for each cpu to 0xF00 | n (where n is the CPUID).
>> Currently it's doing that by reaching in and messing with
>> the mp_affinity field directly, but really it ought to be
>> doing it by setting a property on the CPU, and what it
>> wants isn't somethnig that can be expressed with a simple
>> nr_sockets/nr_cores/etc scheme.
> I am confused now. I thought QOM properties were meant for
> user-visible and/or user-configurable data. I assumed that if
> it's only meant to be used by C code inside QEMU, C functions
> and/or C struct fields were the way to go.
Lots of stuff in a device's C struct is strictly internal
and not to be messed with. I thought that QOM properties
were essentially how a device defined its public (and
typically settable-only-once) config knobs. QOM properties
shouldn't be user-facing (read: stable, required to be
backwards-compatible) interface in general because
we don't really want to tie ourselves down that much.
In fact almost all our QOM objects are not usefully
user-facing at all.