> On Mar 15, 2019, at 2:56 PM, Robert Elz <k...@munnari.oz.au> wrote:
>
> Actually, on a bit more reflection, perhaps the best way forward
> is to work out a better method of implementing the shm() stuff
> puerly out of uvm facilities (with minimal, less than is there now,
> extra data structs) - so shmctl(SHM_LOCK) is just mlock() but perhaps
> with an extra parameter to the underying function which does the work
> to indicate the semantics.
Actually, I don't think the way SVID shared memory is implemented is
particularly bad ... and in fact, the whole reason we have the "anonymous
memory object" (an amusing contradiction in terms :-) is to support SVID shared
memory.
SVID shared memory has a namespace, and that's basically what sysv_shm.c
implements. The underlying support for mapping the shared memory objects and
wiring their pages, etc. is indeed provided by UVM.
-- thorpej
