On Tue, 13 May 2025, Markus Armbruster wrote:
Mark Cave-Ayland <mark.caveayl...@nutanix.com> writes:
On a related note this also brings us back to the discussion as to the
relationship between qdev and QOM: at one point I was under the
impression that qdev properties were simply QOM properties that were
exposed externally, i.e on the commmand line for use with -device.
Can you provide an update on what the current thinking is in this area,
in particular re: scoping of qdev vs QOM properties?
qdev is a leaky layer above QOM.
qdev properties are also QOM properties.
All device properties are exposed externally.
That was clear but the question was if QOM properties (that are not qdev
properties) exist and if so are they also exposed? If not exposed it may
be used for internal properties (where simpler solutions aren't
convenient) but maybe qdev also adds easier definition of properties
that's why they used instead of QOM properties?
We use device properties for:
* Letting users configure pluggable devices, with -device or device_add
* Letting code configure onboard devices
For onboard devices that are also pluggable, everything exposed to
code is also exposed externally. This might be a mistake in places.
If a device is pluggable, theoretically a user could create a machine from
them declaratively, e.g. starting from a "none" machine or like plugging
cards in a motherboard so their properties should be exposed as long as
those properties correspond to the device pins they model or configurable
options. Only properties that are implementation details should not be
exposed because setting them can break the device. There are a few places
where we have such properties. But you say "in places" so I think you
meant the same.
* Letting the machine versioning machinery adjust device configuration
Some properties are meant to be used just for this. They're exposed
externally regardless, which is a mistake.
Question is if we want to allow users to tweak these compatibility
options, like selectively enable/disable when migrating between QEMU
versions or for testing. It might have some uses and maybe that's the
reason why people would like these to go through deprecation instead of
just dropping them. Marking some properties not exposed would get the same
resistance then so may not solve the issue.
Regards,
BALATON Zoltan
