Genode region mapper

[Valery V. Sedletski]

On 19.01.2018 23:33, Norman Feske wrote:
> Hi Valery,
>
>> I also know, that there is a support for managed dataspaces, or nested
>> region maps, which could be useful here (at least, for implementing a
>> shared memory area), but I also know, that nested region maps are not
>> supported on all platforms (like Genode/Linux). So, it would be,
>> possibly, better to avoid using them, unless really needed.
> managed dataspaces are the only mechanism that allow the manual
> organization of virtual address-spaces ranges on Genode. From your
> description, I think that they suffice for your needs as long as each
> address space takes the initialization steps like obtaining the managed
> dataspaces from somewhere (a central service?) and attaching them at the
> desired local address.
Yes, I have an "os2exec" server, which loads binaries of different 
executable formats
(support for which is implemented as a special shared library, per each 
format) into memory.
It parses executable sections to dataspaces, and then passes them to 
client programs, on request.
The client then gets the section dataspaces, one by one, together with 
intended attach addresses,
and attaches them to its own memory.

Os2exec server also maintains the shared memory area in its own memory. 
Each process is run inside a special
l4env binary, which has all system structures moved above the address 
0xa0000000. So, the addresses below are freed up. The private and shared 
areas are reserved at the startup. Then this l4env binary (aka 
"application container") gets the sections of the specified OS/2 binary, 
and the sections of all required DLL's, from os2exec server, attaches
them to its address space, and jumps to the entry point.

So yes, I could be able to create the shared memory area as a single 
managed dataspace in os2exec, and
pass it to each userland process, at its initialization. Also, reserved 
sub-regions could also be
implemented as managed dataspaces, which will go into needed (private or 
shared) areas.


> A managed dataspace can be of any size. It
> contains no mappings unless a real dataspace is attached within. Once
> the managed dataspace is attached to the local address space, the
> virtual-address area spanned by it is not used for any other mappings.
>
> You are right in that managed dataspaces are somehow limited on Linux
> where it is not (easily) possible to remotely manipulate address spaces.
> But the feature set you need - preserving a virtual address-space area
> to be manually managed - should be covered.
Also, I'm wondering, are the stack area and the linker area still 
implemented as managed dataspaces
on base-linux? So, they are the same as on other platforms, but they 
only couldn't be nested? (As I understand,
dataspaces on Linux are not RPC objects indeed, so they are just 
mmap-ped as a file in the same address space,
that is the cause?).
> For reference, you may take
> a look at the handling of the stack area, which is a 256MiB-sized
> virtual-address space window that is sparsely populated with the stacks
> of the component-local threads.
>
> Cheers
> Norman
>
Thanks, will look at it!

I'd like everything to work on Linux as well, though. Still having a 
Genode region map API wrappers, which implement

their own accounting for all VM regions, looks feasible. So, if I use 
these wrappers exclusively, avoiding the

direct usage of Genode RM API's, I'd be able to maintain the required 
address space layout. But I need to think, of course.

WBR,

valery