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

[Peter Maydell]

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

Most of the devices I deal with are not and never will
be sensibly usable with -device. Exposing wiring up
of IRQ and GPIO lines or MMIO regions to the user is
never going to make sense. For x86 most devices are
probably pluggable (and usable with -device), but over
the whole source tree I think the embedded-style device
is in the majority. They're all still worth QOMifying
and having properties for the things board code wants
to modify, though.

thanks
-- PMM