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 <balaton@eik.bme.hu> 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