Re: [Qemu-arm] QOM properties vs C functions/fields (was Re: [Qemu-devel] [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())

[Eduardo Habkost]

On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote:
> On 18 October 2016 at 19:45, Eduardo Habkost <address@hidden> 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.

This interpretation surprises me, because it is the opposite of
what I have seen us doing. Most of our QOM objects and properties
are user-visible and user-configurable using -global, -device,
-object, or qom-set (and probably other QMP commands).

Some QOM properties are internal and we have been using the "x-"
prefix to indicate that, but most of them do _not_ have the "x-"
prefix.

-- 
Eduardo