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_...
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/o...
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