Re: How to mark internal properties

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 12 May 2025 12:54:26 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Daniel P. Berrangé <berrange@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 <thuth@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?

While we are inventing a new API, I'd say that _INTERNAL_ is not the only thing
on my wish-list wrt properties.
It would be also nice to know when a property is set by internal or external user
or if it still has default value.

Basically we are looking at different flags for properties and INERNAL being
one of them.

Maybe instead of specialized macro, we should have a more generic
   DEFINE_PROP_WITH_FLAGS_FOO(...,flags)
So we won't have to rewrite it again when we think of another flag to turn on/off.


From previous uses of x- flag, some of such properties are created as
temporary | developer-only and occasionally as a crutch (still no intended for end user).
But then sometimes such properties get promoted to ABI with fat warnings
not to touch them. Having stable|unstable flag could help here without
need to rename property (and prevent breaking users who (ab)used it if we care).