On Thu, 12 Feb 2026, Zhao Liu wrote:
On Wed, Feb 11, 2026 at 12:28:13PM +0100, BALATON Zoltan wrote:
Date: Wed, 11 Feb 2026 12:28:13 +0100
From: BALATON Zoltan <[email protected]>
Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track
external user input
On Wed, 11 Feb 2026, Zhao Liu wrote:
So another way could be to not use properties for internal settings but add
another set of internal properties for those. These could be set the same
way but stored in a different hash table and not get mixed with
introspectable and user changable properties. But maybe that would be too
much refactoring.
Yes, it may require adding interfaces similar to object_property_add/get/
set, which would need significant changes.
Maybe not that part needs significant changes as you could still use a flag
the same way adding a parameter to object_property_add/get/set to tell it
should put the propery in the internal hash but then you need to add the
other hash and maybe related changes. I don't know how much would those be
but no new interface is needed just extending existing one as you did
already.
Yes, you're right, the flag-related interfaces in this series provide
enough support. But I haven't quite figured out what the advantages of
using an independent hash table would be, or what problems it could
address... I feel like I need to think about it more :).
Storing internal properties in another hash could avoid needing INTERNAL
and USER_SET flags as then there would be no way to set internal
properties other than from code and may save some checks as then you would
not need to special case internal properties in the user
inspectable/settable properties handling. But I don't know how much other
infrastructure it would need and if that would end up simpler than your
approach or not. I think it may be simpler by avoiding the special cases
and flags and clearly separating properties but as you say that would need
more thinking and I did not try to think further just throwing the idea at
you :-). The part creating, setting and storing internal properties should
be simple but I don't know if the usage of these would have a problem when
getting properties use the same interface for both external and internal
properties. But if all these internal properties just set device state
fields then all that's needed might be changing the property definition to
use internal property and the compat props to set such properties (but
compat may use some user settable properties too so this may make those a
bit more complex).
Regards,
BALATON Zoltan
