Re: Physical memory allocation to L4linux

Hey Adam,

Thanks for the input. I will try changing one of the suggested functions. 

It would be great out of curiosity if you could elucidate why the following occurs.  

I see that there is a new iomem region being created and this happens only when I try to read from the mapped region - not until then. But none of this reaches the kernel or maybe I am not sure where to look..

In fact, I see that the init_mem file parses the kernel  memory descriptors to find the regions. So under what circumstances does sigma0 go back to the kernel for mem/io? 

Thanks a lot!
Ramya



> On 15 Sep 2014, at 00:38, "Adam Lackorzynski" <[email protected]> wrote:
> 
>> On Fri Sep 12, 2014 at 16:34:17 +0000, Masti  Ramya Jayaram wrote:
>> I realized that the best place to modify sigma0's capabilities are
>> when it is created. I see that this happens in
>> kernel/fiasco/src/kern/kernel_thread-std.cpp in the init_workload()
>> function. I do not exactly understand how sigma0 gathers all the
>> capabilities - the code is a little hard to parse for me. Could
>> someone explain this to me? Is there a way to pass only limited
>> capabilities to sigma0 -aka, allow the default and then prune the
>> resource tree?
> 
> So, I've changed my mind, let's not modify the kernel but sigma0. This
> seems easier to me. As sigma0 is the root of memory this should not be a
> problem and can be argued.
> Sigma0 handles memory at first-come-first-serve approach and only gives
> it out once, so allocating it before servicing client requests should
> hide it from clients (see memmap.cc). However, there's also an unmap
> call which would need to be handled to not free it again. Another
> approach could be to exclude the memory region when initializing the
> internal data structures in init_mem.cc.  Whatever works/fits better.
> 
> 
> 
> 
> Adam
> -- 
> Adam                 [email protected]
>  Lackorzynski         http://os.inf.tu-dresden.de/~adam/
> 
> _______________________________________________
> l4-hackers mailing list
> [email protected]
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers