>
> 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