qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3


From: Peter Maydell
Subject: Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
Date: Sat, 22 Oct 2016 10:31:11 +0100

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? We have -global but that's a bit
awkward if I'm remembering its syntax correctly.)

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

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]