On Fri, 17 Jan 2025 at 06:19, Akihiko Odaki <akihiko.od...@daynix.com> wrote: > Let me explain my and Peter Xu's solutions by listing object references. > It will abstract the details away and allow applying the analogy of > other reference counting systems like Objective-C. > > "Real" reference relationship > ----------------------------- > > First, I'll introduce one basic rule: > > Rule 1. If A needs B, let A refer to B. > > Now, There is an owner and a memory region. The owner needs the memory > region to function. The memory region needs the owner to provide to > allocate itself and e.g., to provide MemoryRegionOps for > memory_region_init_io(). So we will make a bi-directional reference > between the owner and the memory region. > > O (Owner) -> MR (Memory Region) > MR -> O > > Now, let's think the case where there is a container and subregion, and > they are owned by different objects. The container needs the subregion > to satisfy its accesses, and the subregion needs the container for > memory_region_find(). So this relationship is also bi-directional. > > CO (Container's Owner) -> C (Container) > C -> CO > SO (Subregions' Owner) -> S (Subregion) > S -> SO > C -> S > S -> C > > Let's think someone took a reference to the container e.g., for DMA. > This mean we add the following reference: > > DMA Controller -> Container > > This will ensure all of Container, Container's Owner, Subregion, > Subregion's Owner are alive during the DMA. > > "Weak" references > ----------------- > > Next, I'll impose the restriction that prevents circular references. To > avoid circular references, we'll stop counting references for one > direction. In other words, we'll make some references "weak". Weak > references are prone to be dangling (in Objective-C or other platforms, > such references will be usually replaced with nil-like values).
I'm not sure this is really how we think about the lifetimes of these objects, though. In particular, we definitely don't ever expect, for instance, the link from a memory region to its owner to be dangling. I think what we actually have is: * the thing which really has a reference count is the device object * this device owns various things (irqs, child objects, memory regions, etc) * we expect that when we destroy the device that all these other things it owns also should be destroyed * some parts of the system have free-floating memory regions which don't have an owner * parts of the code have to deal with both the "MR belonging to a device" and the "MR not belonging to a device" case > Comparison between the two patches > ---------------------------------- > > I'll compare them by showing pros and cons of Peter Xu's patch. > > Pro: > a. Will not add yet another direct reference to memory regions where > currently there can be only one reference from the owner to each memory > region. > > Cons: > b. It requires two new rules. > c. C will see its reference to S to disappear at random timing due to a > weak reference. C should never see a reference to S disappear at a "random time". Either (a) we are going to clean up all these objects because they all belong to the same device and they get destroyed at the same time, or (b) something should be cleanly removing S from C. -- PMM
