getc()

[Ben Leslie]

On Sun Apr 22, 2007 at 06:18:19 -0700, Peter Nguyen wrote:
>
>Hi, 
>
>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.
>

Hi Peter,

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.

Cheers,

Ben