On Wed, Aug 18, 2021 at 8:34 PM Joan Lledó <jlle...@mailfence.com> wrote: > El 18/8/21 a les 0:13, Sergey Bugaev ha escrit: > > you can no longer get the underlying memory object with vm_region () > > How so? reading the docs I understood it does: > > https://www.gnu.org/software/hurd/gnumach-doc/Memory-Attributes.html > > "The port object_name identifies the memory object associated with this > region"
Yes; the docs could have been clearer about this — and I was myself confused about this not long ago. What it gives you is a _memory object name port_ which "identifies" the memory object, in the sense that you can get name ports for two regions (even from different tasks) and they'll compare equal if it's the same memory object mapped into both. And that's about the only thing you can do with the name port. It's *not* the actual port to the underlying memory object. > > (Well in fact what actually changed is that gnumach at some point > > allowed the use of "memory object name ports" in vm_map (), and now > > once again doesn't. > > vm_map does receive the memory object as parameter: > > https://www.gnu.org/software/hurd/gnumach-doc/Mapping-Memory-Objects.html > > "memory_object is the port that represents the memory object: used by > user tasks in vm_map" Previously, as a GNU Mach extension, you could also pass the memory object *name* port (one you get from vm_region ()), instead of the memory object port. But not anymore. > > It never allowed you to get the actual memory > > object.) > > vm_map receives a memory object, doesn't return it Yes. What I'm saying is vm_region () gives you the name port, which previously could be used in vm_map () much like the memory object port (this was allowed to enable mremap () to be implemented). vm_region () never gave out the actual memory object port, but the name port could be used in vm_map () in a similar way to the real memory object port. Sergey