On Wed, Oct 07, 2020 at 03:55:58PM +0200, Paolo Bonzini wrote: > On 07/10/20 15:02, Eduardo Habkost wrote: > > On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote: > >> On 07/10/20 00:06, Eduardo Habkost wrote: > >>> Hi, > >>> > >>> While trying to understand how QOM properties are used in QEMU, I > >>> stumbled upon multiple cases where alias properties are added at > >>> realize time. > >>> > >>> Now, I don't understand why those properties exist. As the > >>> properties are added at realize time, I assume they aren't > >>> supposed to be touched by the user at all. If they are not > >>> supposed to be touched by the user, what exactly is the purpose > >>> of those QOM properties? > >> > >> In the case of GPIOs, I think they will be used by other devices that > >> are added afterwards. > > > > Do you know how exactly are they used? Is this always wrapped > > behind a specific API for GPIOs, or the devices can look for the > > properties directly? > > It is always wrapped, but (as far as I recall, because I have never > worked with GPIOs) they are intentionally QOM properties and not just as > an implementation detail. It's meant to be accessible to the user if > only through qom-get/qom-set.
Being accessible for debugging would be OK. I'm just worried about dynamic QOM properties being part of a stable and supported API. > > Paolo > > > I'm concerned by the possibility of having QOM properties as an > > undocumented part of an internal API. > -- Eduardo