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