Reason why I am asking is that this would be a nice way for userland
processes to create a region of memory - (a subspace, if you would ;-)
that can be shared across processes. Instead of creating discrete pages
to be shared (ala SYSV SHM), why not allow userland processes to create
(and thus share) discrete sub-regions - which can independently have
pages allocated/freed within that subspace?

This would be most useful for creating a "growable" (and thus
shrinkable) region of CONTIGUOUS virtual memory that can be shared
across processes - (much like what currently happens in the kernel ?)
In contrast SYSV SHM doesn't support contiguous regions across shmget()
calls, save the "accidental" shmat() of two or more shmid'd regions next
to each other in the client process's address space.

Is there an alternate way to add in this functionality besides using
submaps?

Thanks,

-Jason Kim.


Michael Shalayeff wrote:
> Making, drinking tea and reading an opus magnum from Jason W. Kim:
> [Charset ISO-8859-1 unsupported, filtering to ASCII...]
>
>>Hi, all
>>
>>I'm looking through the uvm code in 3.6, and ran across a puzzling
>>comment -
>>
>>near uvm_map.c:2108
>>/*
>> * uvm_map_submap: punch down part of a map into a submap
>> *
>> * => only the kernel_map is allowed to be submapped
>> * => the purpose of submapping is to break up the locking granularity
>> * of a larger map
>>
>>My question is, why is the creation of submaps limited to only the
>>kernel? (Neither the tech archives nor cranor's thesis answers this
>>question so ...)
>>
>>Secondly, what would it take to get the submap functionality working for
>>userland? Are there any specific "gotcha"'s that I need to be aware of
>>for getting the submap stuff working in userland?
>
>
> the question is: why?
>
> cu