On Mon, 12 May 2025, Xiaoyao Li wrote:
On 5/12/2025 6:54 PM, Markus Armbruster wrote:
Daniel P. Berrangé<berra...@redhat.com> writes:
On Mon, May 12, 2025 at 09:46:30AM +0100, Peter Maydell wrote:
On Fri, 9 May 2025 at 11:04, Thomas Huth<th...@redhat.com> wrote:
Thanks for your clarifications, Zhao! But I think this shows again the
problem that we have hit a couple of times in the past already:
Properties
are currently used for both, config knobs for the users and internal
switches for configuration of the machine. We lack a proper way to say
"this
property is usable for the user" and "this property is meant for
internal
configuration only".
I wonder whether we could maybe come up with a naming scheme to better
distinguish the two sets, e.g. by using a prefix similar to the "x-"
prefix
for experimental properties? We could e.g. say that all properties
starting
with a "q-" are meant for QEMU-internal configuration only or something
similar (and maybe even hide those from the default help output when
running
"-device xyz,help" ?)? Anybody any opinions or better ideas on this?
I think a q-prefix is potentially a bit clunky unless we also have
infrastructure to say eg DEFINE_INTERNAL_PROP_BOOL("foo", ...)
and have it auto-add the prefix, and to have the C APIs for
setting properties search for both "foo" and "q-foo" so you
don't have to write qdev_prop_set_bit(dev, "q-foo", ...).
If we make intent explicit with DEFINE_INTERNAL_PROP_FOO(), is repeating
intent in the name useful?
+1 for DEFINE_INTERNAL_PROP_FOO(). I have the same thought.
We need something in code to restrict the *internal* property really
internal, i.e., not user settable. What the name of the property is doesn't
matter.
What's an internal property? Properties are there to make some field of an
object introspectable and settable from command line and QEMU monitor or
other external interfaces. If that's not needed for something why is it
defined as a property in the first place and not just e.g. C accessor
functions as part of the device's interface instead? I think this may be
overusing QOM for things that may not need it and adding complexity where
not needed. It reminds me of patches that wanted to export via-ide IRQs or
ISA IRQs just to be able to connect them to other parts _of the same chip_
becuase this chip is modeled as multiple QOM objects for reusing code from
those. But in reality the chip does not have such pins and these are
internal connections so I think it would be better to model these as
functions and not QOM constructs that the user can change. In general, if
the device or object has an external connection or a knob that the user
may need to change or connect to another device (like building a board
from parts you can wire pins together) then those need properties or
qemu_irqs but other "internal properties" may need some other way to
access and often simple accessor functions are enough for this as these
internal properties are only accessed form the code. That way we would not
need even more complexity to hide these from the user, instead of that
just don't expose them but use something else where a property is not
needed. A property is just like an accessor function with additional
complexity to expose it to other interfaces so it's externally settable
and introspectable but we don't need those for internal properties so we
can drop that complexity and get back to the accessor function at the
bottom of it.
Regards,
BALATON Zoltan
