mmap implementation for ANON mapping with desired address

[Alexander Tormasov]

Hi Norman,

sorry to bother you

>> Problem I see here is a free operation: it just free the block with requested address, and do
>> not touch others, gap-related blocks. For me it is not obvious that they need to be free,
>> because in the code (e.g. by unmap()) I do not see explicit free of other allocated structures,
>> in particular, dataspace extension or related block metadata.
> 
> That's another reason why the mmap support needs additional
> infrastructure. I think of a registry of mmap mappings. The registry
> entries store all the meta data required. They can be allocated on the
> 'Kernel::_heap'. The actual memory is allocated as RAM dataspaces. The
> 'Libc::Mem_alloc' is not required.

can you give me an example how I can obtain this Kernel::_heap?

initially I try something like this (from libc)

/* get Kernel::_heap from Libc */
Genode::Allocator &alloc = reinterpret_cast<Libc::Env_implementation &>(env).vfs_env().alloc();

/* and use it as aux data storage */
vm_reg.construct(env, reinterpret_cast<Genode::Heap &>(alloc));

but obvious that this will not work normally because (again) metadata space can’t be taken from this «main» process heap (this is the same address space for component which can clash with main program allocation).

I suspect that if I make inside my component something like
    Heap _heap { _env.ram(), _env.rm() };

then again I will hit the same problem of clash of local virtual address with this metadata storage?
How to «hide» this data from component programs?
Or I can’t hide and need artificially pre-alloc area for such data and make separate heap based on this?

Do you have any samples?

Sincerely,
	Alexander