Peter Nguyen petern at
Thu Apr 26 03:50:21 CEST 2007

OK, so with that in mind, where does the polling take place?  I might be
wrong in saying this, but is there a portion of code that deals directly
with the polling of I/O?  The reason i ask this is that i think that the
polling of I/O has an affect on the performance monitoring facilities, more
specifically when a performance counter overflows.  This would, in turn,
have an affect on the ability to take samples given that samples might not
be taken while waiting for input.


Ben Leslie-2 wrote:
> 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,
>>providing some facilities for profiling in L4 via sampling.  Right now,
>>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
>>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
>>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
>>other facilities available for provide an alternative means for providing
>>input in an application.  The reason why i am asking about whether getc()
>>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
>>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
>>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
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at

View this message in context:
Sent from the L4 mailing list archive at

More information about the l4-hackers mailing list