On Wed, 28 Jan 2026 at 11:40, BALATON Zoltan <[email protected]> wrote: > OK I try to summarise the motivation again: > > 1. Documentation in docs/devel/memory.rst says that memory regions' > lifecycle is managed by QOM and they are freed with their owner or when > nothing else uses them. This is also already implemented for a long time > as described but cannot be used because the only constructors available > kill this feature when calling object_initialize that clears the free > function added by object_new. (The life time management is implemented > through adding memory regions as children to the owner and unparenting > them on freeing the owner which decreases ref count of the memory region > and will free it when nothing else references it as far as I can tell.)
If we have leaks because of our very common pattern of "embed a MemoryRegion struct in the device state struct" then we must fix those, because there's no way we're going to convert all that existing code to a new set of APIs. But I was under the impression we had already dealt with those, because MRs track their owner's refcount, and don't have their own independent one ? > These are my motivation for this change. What is the motivation for using > embedded memory regions instead and against this change? Simply that it's a consistent pattern we use in a lot of the codebase: the device embeds a lot of the structs it uses, rather than allocating memory for them and keeping pointers to that allocated memory. We still have also various older device models that use the previous pattern of "allocate memory and have pointers" too, but most new code doesn't do that. I think we should for preference write code in one pattern, not two, and "embed structs" seems to be what we have mostly settled on for new code. There is an argument to be made that the pointer model would fit better with a possible future world of "the user can wire configurably wire up their own board model from devices", and that it works better in a part-Rust-part-C world where the two different languages don't have convenient access to the exact size of structs defined in the other language. But that future model is not something anybody has yet really fleshed out in any detail, so it's still a bit speculative. I'm not actually 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 examine proposed new APIs and all be on the same page about the design patterns we want and it will be clearer to reviewers whether the new APIs fit into those patterns or not. thanks -- PMM
