mmap implementation for ANON mapping with desired address

[Norman Feske]

Hello Alexander,

> as I see, current interface of libc alloc() assume that all memory
> stored inside is committed (has been called _ds_pool.expand()), so, I
> can’t reserve memory and populate it by demand naturally, without
> libc alloc changes?
For this reason, I wrote in my previous email:

  "This feature would work independently from the 'Libc::Mem_alloc'.
   I think that the use of 'Libc::Mem_alloc' by 'mmap' is not the right
   way to go when taking mmap beyond it current scope."

> By the way, I see a couple of references in genode docs to the way to
> "use managed dataspace" and "populate it by phys memory by demand",
> while no references to code samples provided? How I can reserve
> virtual memory range in component without backend storage, in what
> allocator?
A high-level description is provided by the Genode-Foundations book:


https://genode.org/documentation/genode-foundations/20.05/architecture/Core_-_the_root_of_the_component_tree.html#Region-map_management__RM_

You may find the use of the RM service by the JVM instructive:


https://github.com/genodelabs/genode-world/blob/master/src/app/jdk/lib/jvm/os_genode.cpp#L4325

For further use cases, consider grepping the source tree for the
corresponding header:

  cd genode/repos
  grep -r "\<rm_session/connection" *

> What is a difference between them (except difference in DS_SUB_OFFSET
> vs local_attach_addr)? More specifically, between returned addresses
> from sub_rm.attach_at() and env.rm().attach_at()?
Whereas 'env.rm().attach_at' refers to the virtual address space of the
component, 'sub_rm.attach_at' refers to the layout of the managed
dataspace created via the RM service. The address of the former is a
virtual address, the address of the latter is an offset relative to the
beginning of the managed dataspace.

> otherwise how this alloc will take memory from it?

By allocating RAM dataspaces directly via 'env.ram().alloc' and
attaching it to an offset within the managed dataspace.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth