benno at ok-labs.com
Tue Apr 24 14:57:37 CEST 2007
On Sun Apr 22, 2007 at 06:18:19 -0700, Peter Nguyen wrote:
>I'm currently messing around with L4 at the moment. More specifically, i'm
>providing some facilities for profiling in L4 via sampling. Right now, i'm
>trying to implement an exception handler for the Performance Measurement
>Counters on the PowerPC architecture. In providing calls to these
>facilities via the pingpong root-task, i seem to run into problems with
>input. Essentially, while the root-task is waiting for user input, it seems
>as if the exception is not kicking in until i enter a character. The
>exception that should be handled is a performance monitor exception (where
>one of the counters overflow). Basically, the overflow takes place such
>that a significant amount of instructions have been executed when
>theoretically it should be signalled earlier.
>In accepting input, the root-task (which i didn't write myself) uses getc()
>to obtain such input. My question is basically whether getc() blocks
>everything and sits there until a character is received? I suspect that
>this is most certainly the case. If so, does anyone know whether there are
>other facilities available for provide an alternative means for providing
>input in an application. The reason why i am asking about whether getc() is
>a factor or not is that in providing an infinite loop, the
>exception/interrupt kicks in at the right time ie. when the counter
>overflows, the resulting counter value is slightly above the overflow value
>eg. the counter overflows when the contents of the register is 0x80000000.
>When the exception kicks in, the "final" value is 0x80000012 as opposed to a
>random value in the case with a root-task that requests input.
>Any help would be greatly appreciated.
Which version of L4 are you using?
It is certainly the case that in NICTA's L4-embedded (now OKL4), and the
L4Ka kernel, that a root task getc() ends up calling L4_KDB_ReadChar_Blocked(),
which as you correctly surmiase ends up just polling inside the kernel
waiting for serial input.
I suspect that if you are using Dresden L4 it is probably also the case.
More information about the l4-hackers