Hi Martin, Thanks, that was very informative and made things a lot clearer to me - it should keep me going for the next few weeks! Enjoy your holiday, CheersNick
Hi Nick,
I'm pleased to hear that you've found the time to proceed.
...
You're right concerning the directory 'src/platform'. Due to the fact that 'base-hw' solely targets ARM systems for now, the separation of generic and platform specific code is not proven very well. I've annotated this issue, thank you!
Moreover i'm not sure if i've understood you right regarding 'mode_transition.s'. The file does not really handle or control any type of exception. It's purpose is on the one hand to only catch exceptions, wich occur in userland, save the interrupted user execution-state and exception information, and get back to the kernel enviroment to re-run 'kernel()'. On the other hand it offers also the opposite direction, that is resuming a given user execution-context in userland once 'kernel()' returns. This way the handling of the concrete exception, whether it is an interrupt, a page fault or a syscall, resides completely in 'kernel()'.
If you were looking for the resolution of page faults, even 'kernel()' is not the final destination. When kernel detects the presence of a page fault, the function 'handle_pagefault()' only checks if the fault was caused by a translation miss. If this is the case a pager might resolve the problem by expanding the according page table. Thus kernel composes an appropriate IPC message to the pager that is identified by the thread object of the faulter. The pager normally is a thread in Genodes 'core' process, wich itself asks the so called "Region Manager" of the faulter for a region mapping that covers the fault. If a mapping is found the pager modifies the page table accordingly. The only process that doesn't need pagers is 'core'. Because 'core' is the first process in Genode, gets initialized by 'kernel()' and must be trusted anyway, its page table gets filled with static 1:1 translations initially by kernel. Once this is done, kernel itself joins this process, so userland threads in 'core' and the kernel "thread" share the same address space.
Long story short, the configuration of virtual/effective addresses depends, except of 'core' on the region managers, wich themselves are instructed through the RM-sessions (base/include/rm-session/rm_session.h) they provide to their RPC-clients.
I hope this gives you a rough picture of Genodes virtual-address management, even it is a somewhat far-reaching explanation.
Cheers, Martin
On 08/08/2012 06:24 PM, Nick Betteridge wrote:
Hi Martin,
...
I have been slowly reading through your arm assembler, trying to understand how genode works.
Just one thing - you have partitioned both arm processors and platforms into named directories, except for base_hw/src/platform, which contains arm assembler. Do you intend to refactor this into something like base_hw/src/platform/arm?
Just one more thing, am I right in thinking
'base-hw/src/core/arm_v7a/mode_transition.s'
is just for interrupt control? I can't find anything for configuring virtual/effective addresses - perhaps this is done in 'c' (I haven't read the c yet) - in openrisc this is handled in the supervisor mode.
Cheers Nick
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main