getc()

[Peter Nguyen]

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.

Peter


Ben Leslie-2 wrote:
> 
> 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
> 
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 
> 

-- 
View this message in context: http://www.nabble.com/getc%28%29-tf3626544.html#a10192876
Sent from the L4 mailing list archive at Nabble.com.