On Sat, Oct 16, 2021 at 2:27 PM Sergey Bugaev <buga...@gmail.com> wrote: > I don't think it should *ever* return the original object back. I'd > rather it always made a new proxy that internally references the > object and caps max_protection to that of the region.
I also think there's a philosophical difference in how we think about this RPC. The way you wrote it, it always returns the original memory object that has been used to vm_map () this region (so, either the underlying object or a proxy to it). So if you call vm_map () and then immediately vm_pager (), you'll get the very same port back. (Is that correct?) But the way I think of it, it doesn't return *the* memobj, it returns *some* sort of memobj (a proxy) that can be vm_map'ped to map the same pages as the original region. But there's no expectation that it will return the very original memobj, only something that gives you the same pages/data in the end. With your design, you have to keep the proxies alive even after the userland is done with them, i.e. after vm_map (proxy); mach_port_deallocate (proxy), just to return the same proxy back in case someone asks. In my design, proxies are short-lived (unless the userland keeps them alive): you get a proxy from the kernel, you pass it to someone, they map it (the underlying memobj is entered into the VM map), they destroy the proxy, and that's it. If somebody asks, we create a fresh new proxy to the same underlying memobj. Again, the userland should hold no expectations about port equality here. And this philosophical difference is also reflected in the RPC name: your vm_pager () is "get the pager behind this region", my vm_create_proxy () is "make a proxy of memory in this region". I hope this makes at least some sense. Sergey
