On 16/06/2026 17:40, Daniel P. Berrangé wrote:
On Tue, Jun 16, 2026 at 05:12:27PM +0100, Peter Maydell wrote:
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".
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 think it depends: we do already have hot paths where people use a
direct pointer reference instead of an object property lookup, but these
cases are generally in the minority. And there's no reason why for those
cases the pointer couldn't be cached within the device state during
device realize or similar, along with a suitable comment of course.
The other case in which I've found device pointers in the device state
useful is during low-level debugging sessions i.e. where state is
corrupted enough that calling object functions in gdb may fail.
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.
ATB,
Mark.
