On Tue, Jan 27, 2026 at 03:10:28PM +0100, BALATON Zoltan wrote:
> This series does not convert everything but opens the way to do that and
> simplify objects by only storing things in the state that are really needed
> by the object and let QOM manage what it can. I'd really like to avoid
> having a list of unused stuff in the state struct just because I can't use
> something that works and documented just no API to actually use it. Cf.
> sii3112 state after this series:
>
> struct SiI3112PCIState {
> PCIIDEState i;
>
> SiI3112Regs regs[2];
> };
>
> vs. your standard:
>
> struct SiI3112PCIState {
> PCIIDEState i;
>
> MemoryRegion mmio;
> MemoryRegion bar0;
> MemoryRegion bar1;
> MemoryRegion bar2;
> MemoryRegion bar3;
> MemoryRegion bar4;
> SiI3112Regs regs[2];
> };
The latter solution is fine at least to me.
I respect your preference on how it can be done, but IMHO it is subjective,
and I tend to agree with Peter that we should try to stick with one way of
solving problems, unless very necessary.
In the last three patches the MRs do not look need dynamic deallocation to
me at all.. Introducing fully dynamic MR allocations only for those is an
overkill to me. I'm not fully convinced we need to merge 600+ new LOCs for
new APIs just for them.
We have real but rare users of dynamically allocated MRs, currently AFAIU
we're leaning towards having an object wrapping the MRs needed, when one
wants to provide a complete lifecycle for the MR so the memory backing the
MRs can be freed completely separately from the parent object.
Thanks,
--
Peter Xu
