On Tue, Apr 30, 2024 at 10:44:20AM +0100, Peter Maydell wrote: > On Tue, 30 Apr 2024 at 08:36, Markus Armbruster <arm...@redhat.com> wrote: > > > > Daniel P. Berrangé <berra...@redhat.com> writes: > > > * /machine to get the rtc-time property value > > > > This is an alias to the RTC device's "rtc-time" property. Only some > > machines define it. Useful because the actual property depends on > > machine type and configuration. For q35, it's > > /machine/unattached/device[N]/rtc/date, where N can vary. > > > > If we moved the southbridge out of the /machine/unattached dump, we'd > > have something like /machine/q35/ich9-lpc/rtc/date. Stable, but you > > have to know the machine type to find it. > > Do we really want to call that stable, though? If we ever > wanted to refactor the devices internally it might change. > > My gut feeling is that exposing something we want to > be stable as a specific "this is obviously an externally > exposed identifier" (e.g. in the way we do by having an > rtc-time property alias on the machine object) is more > likely to be reliable than trusting that a QOM path all > the way down to a specific device is never going to be > rearranged.
Yes, the ideal would be that anything libvirt needs apriori knowledge of should be accessible via an 'id' value assigned by libvirt. QOM paths should only be used by libvirt if they're obtained dynamically from a prior QMP query, not hardcoded in libvirt source. That would avoid the QOM tree paths becoming API/ABI. The challenge is that it is hard to predict what we might need to access, that does not yet have an 'id' alias assigned, which is how we ended up using QOM paths for a few things, where 99% of the timee we use 'id' aliases. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
