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

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

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

"Device not pluggable" does not imply "device has no configuration knobs
a user may legitimately want to mess with".  Plenty of onboard devices
have such knobs.

Right now, users configure these mostly via board-agnostic options like
-serial.  Anything that doesn't fit the mold can't be configured that
way.

However, A fully mature QOM as I envisage it would provide users access
to QOM properties for onboard devices, too.  Not with -device,
obviously, but with qom-set and similar, as Eduardo said.  If any of
these properties are not for users, they should be marked as such.  Just
like for pluggable devices.

Perhaps non-pluggable devices tend to have more "not for users" QOM
properties than pluggable ones, I don't know.  But that would be a
*quantitative* difference, not a *qualitative* one.