Re: [RFC 0/7] qom: deprecate embedded objects and instance properties

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Jun 16, 2026 at 05:12:27PM +0100, Peter Maydell wrote:
> On Tue, 16 Jun 2026 at 16:56, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > QOM has two rather unusual / surprising features historicall
> >
> >  * The ability to embed a QOM instance's memory inside another
> >    struct
> >  * The ability to register properties against the instnce
> >    instead of struct
> >
> > While they both look convenient on the surface, they also
> > have significant undesirable side effects (see the commit
> > message for each patch for details).
> >
> > The premise of this series is that their convenience does
> > not outweigh their downsides, and we would be better off
> > long term by eliminating their usage, rather than trying
> > to add more hacks on top to mitigate their downsides.
> 
> The thing I would like to see before we mark object_initialize_child
> and friends as deprecated is clear documentation of "this is how
> we would like you to write 'container/SoC' style devices, here is
> an device written to the approved style you can look at".

Do we have any documentation currently that touches on
this area that we can start from / adapt to best
practices ?  I can do adaptation, but I'm not an expert
on Device code, so probably not best placed to write a
new doc fro mscratch.

> Currently we have in the codebase a pretty wide range of
> different ways to write devices:
>  - really ancient, not QOM/qdev at all
>  - qdev style (lots of Device* pointers)
>  - embedded-struct style
> and I'm not sure if this would be adding a fourth style, or
> rolling back to qdev style.

Per my commit message in the PIIX patch, I'm not convinced
we need to store any device pointers in the instance
structs at all in many (possibly most) cases. The instance
struct fields are mostly only referenced during creation
time and then never again, with the QOM 'child' property
holding the permanent reference.

> I'm not opposed to the idea of making a design decision that this
> struct-embedding is no longer what we want to do, and defining
> that something else is our new best practice for how to write devices.
> But I think we would need to start by reaching a consensus that that
> *is* what we want to do, and documenting that "best practice" somewhere
> in docs/devel/. Then we can all be on the same page about the design
> patterns we want and it will be clearer to reviewers whether new
> code and new APIs and conversions of old code fit into those
> patterns or not.
> 
> I think we're getting closer on the "consensus" part but
> the "document the new best practice" part is important I think.

Yep, best practice docs must be a key part of the story.

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 :|