Hello Alexander,

On 21.09.20 23:33, Alexander Tormasov via users wrote:
> 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?

the libc already contains such an internal 'Heap' object. It is created
at [1] and passed to the constructor of the 'Libc::Kernel' [2]. The
Libc::Kernel keeps a reference to this 'Heap' instance [3]. When I spoke
of 'Kernel::_heap', I was referring to this instance.

Just below [1], you can see that the heap reference is passed to the
'Libc::init_fd_alloc' function. This way, the compilation unit
fd_alloc.cc [4] gets hold of this 'Kernel::Heap' instance and can
thereby use it for the allocation of libc-internal meta data, in this
case 'File_descriptor' objects.

The 'file_operations.cc' compilation unit that hosts the 'mmap'
implementation already has a 'Libc::init_file_operations' function but
the function does not take an 'Allocator &' as argument. In order to
allow this compilation unit to use the 'Kernel::_heap', you'll have to
extend this function with an 'Allocator &' argument (you may take
fd_alloc.cc as blueprint), and adjust the call at [5] accordingly
(passing '_heap' as second argument).

[1]
https://github.com/genodelabs/genode/blob/master/repos/libports/src/lib/libc/component.cc#L40
[2]
https://github.com/genodelabs/genode/blob/master/repos/libports/src/lib/libc/component.cc#L49
[3]
https://github.com/genodelabs/genode/blob/master/repos/libports/src/lib/libc/internal/kernel.h#L129
[4]
https://github.com/genodelabs/genode/blob/master/repos/libports/src/lib/libc/fd_alloc.cc
[5]
https://github.com/genodelabs/genode/blob/master/repos/libports/src/lib/libc/kernel.cc#L477

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

_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users

Reply via email to