On Tue, 2004-08-03 at 21:57, Marc Kleine-Budde wrote: > On Tue, Aug 03, 2004 at 06:56:10PM +0200, Marc Kleine-Budde wrote: > > Hmm - After winding though about 4-5 layers[1]....this function calls > > the svctable.faulthandler, only if a xnthread is active. > > > [1] From there fault to the handling..... > > > > 1) > > rthal catches all HW faults from adeos: > > adeos_catch_event(trapnr,&rthal_trap_fault); > > > > 2) > > rthal_trap_fault calls rthal_trap_handler if in RT-mode > > note: rthal_trap_handler is a functionpointer > > > > 3) > > rthal_trap_handler is set by rthal_set_trap_handler > > > > 4) > > during xnarch_init(): > > rthal_set_trap_handler(&xnarch_trap_fault); > > > > 5) > > in xnarch_trap_fault(): > > xnpod_trap_fault() is called > > > > 6) > > xnpod_trap_fault() finally calls the faulthandler defined in the > > svctable > > > > note: steps 1, 3, 4 are done during system-setup, not runtime > > > > during faul-runtime its: > > adeos -> rthal_trap_fault -> xnarch_trap_fault -> xnpod_trap_fault -> > > svctable.faulthandler > > I thought you would have said sth to this.... > > The exception of the faults is very labyrinthic :) It goes through
Labyrinthic would mean that many ways are possible for progressing from this code path including a bunch of dead ends. This is clearly not the case here. > several 'real' layers. This was needed in RTAI 3.0 and 3.1 but I think > If somebody has enough/too much :) time, it should be redesigned... > xnpod_trap_fault should be directly registered within the Adeos layer. > Nope, it should not. You still have to deal with on-demand memory mappings triggering valid page faults with the "real" HAL. But you don't have such concern on top of the UVM or the simulator, which can run the very same nucleus over virtual machines without Adeos in the picture; so you definitely need [5]. Since the nucleus must have its say about what needs to be done unconditionally upon a fault (well, since it's the kernel, right?), you need [6]. But well, maybe something in the upper layer might be interested in taking some actions before the fault event is finally processed by the nucleus applying its default procedure which suspends the faulty thread, so calling the user-defined fault handler through the service routine is quite useful here. > At least something for someones TODO list :) > I've something better for the TODO list. Have the following written a zillion times in the documentation: Good layering provides efficient structuring, bad layering is no layering... Good layering provides efficient structuring, bad layering is no layering... Good layering provides efficient structuring, bad layering is no layering... Good layering provides efficient structuring, bad layering is no layering... Good layering provides efficient structuring, bad layering is no layering... Good layering provides efficient structuring, bad layering is no layering... Good layering provides efficient structuring, bad layering is no layering... Ad lib. :o) > > > just my 2 cent - Marc -- Philippe.
