On Tue, 16 Jun 2026 at 16:56, Daniel P. Berrangé <[email protected]> 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". 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. (Borrowing a paragraph I wrote last time this came up:) 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. thanks -- PMM
