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@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers