On Tue, Jun 16, 2026 at 05:15:22PM +0100, Peter Maydell wrote: > On Tue, 16 Jun 2026 at 16:56, Daniel P. Berrangé <[email protected]> wrote: > > > > The QOM APIs currently allow objects to be either allocated directly > > on the heap, or statically embedded inside the struct of another object. > > > > For the latter QOM has logic to avoid calling 'free' on the object when > > finalizers complete, however, this is not sufficient to make the > > practice safe. > > > > Users of QOM expect that if they call "object_ref" to acquire their own > > reference, then object will never be freed as long as they hold it. > > > > This expectation is broken when an instance is embedded, as the "owner" > > object's may be finalized, which frees the memory that is storing the > > embedded QOM instance, even if its ref-count is still live. > > > > Worse still is that a user of a QOM object cannot easily tell if the > > instance they're using is embedded or directly heap allocated. > > > > Mark the APIs for embedding objects as deprecated as the first step > > towards removal of this flawed design concept. All objects must now > > be directly heap allocated going forward, and existing usage must be > > incrementally converted. > > I think if you mark an API that we call in 800+ places and 150+ files > as deprecated, mostly what will happen is nobody ever turns on the > --enable-deprecated option because the output will be full of noise...
That is a challenge. The baseline is that developers have no visibility of use of deprecated APIs at all, and we barely even document them. My thought is that even if --enable-deprecated is rarely enabled, at least having QEMU_DEPRECATED visible in the header files is a red flag for developers to look elsewhere for their solution. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
