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" adam@os.inf.tu-dresden.de 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 adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers