Re: gnumach RPC: get info about the calling task

[Sergey Bugaev]

On Sat, Oct 16, 2021 at 2:27 PM Sergey Bugaev <bugaevc@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