Igor Mammedov <imamm...@redhat.com> writes:
> On Mon, 12 May 2025 12:54:26 +0200
> Markus Armbruster <arm...@redhat.com> 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?
>
> 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.
We commonly assume "value is default implies user didn't touch it",
which is of course wrong unless it's a value the user cannot set.
> 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).
I think QAPI's explicit 'unstable' and 'deprecated' flags have been a
success. Their meaning is clear, and they come with documentation
(because adding them without won't compile).
Pushing QOM closer to QAPI when we can makes sense to me.
