Re: [Qemu-ppc] [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 21 October 2016 at 19:26, Markus Armbruster <address@hidden> wrote:
>> "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.
>
> Yes, you're right about this. (What's the command line
> equivalent of qom-set?

Command line isn't implemented.

>                        We have -global but that's a bit
> awkward if I'm remembering its syntax correctly.)

-global changes a device property default value.  You can abuse it to
set a specific device's property only when there's at most one instance.

>> 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.
>
> I agree that it's not really qualitative, but a pluggable
> device's properties are all by definition for the user
> to set (since the user is the only one who can set them).
> In a pre-plugged device, although there may be a lot of
> properties, some of them won't be usefully changeable
> in the context of this device in this board (ie if you
> mess with them you'll just break things). We don't have
> any way for the board to say "this stuff isn't for the
> user", I think.

The closest we have now is the x-prefix convention.

Perhaps we could use a flag to mark certain properties as "not
user-settable", similar to how we mark devices as "not pluggable"
(really: can be created only by board code, not the user).