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.
Peter N
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
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
On Wed Apr 25, 2007 at 18:50:21 -0700, Peter Nguyen wrote:
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.
On our kernel this happens within the kernel itself. There is also a non-blocking version which allows you to perform the polling at user-level itself. I would suggest you do this which would possibly avoid the problems you are seeing.
OK. Where is this code located?
I'm currently using L4Ka::Pistachio, API version 0x84.0x5, Kernel ID 4.2 (as stated when printing out the KIP in open firmware).
Some other questions:
1) Are external interrupts disabled during the polling process as well? 2) Forgive my ignorance, but is L4 multithreaded? I'm asking this because of the minimal nature of a microkernel (which may not require multithreading given the minimal code that theoretically is there to execute).
Ben Leslie-2 wrote:
On Wed Apr 25, 2007 at 18:50:21 -0700, Peter Nguyen wrote:
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.
On our kernel this happens within the kernel itself. There is also a non-blocking version which allows you to perform the polling at user-level itself. I would suggest you do this which would possibly avoid the problems you are seeing.
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Sun Apr 29, 2007 at 21:31:03 -0700, Peter Nguyen wrote:
OK. Where is this code located?
I'm currently using L4Ka::Pistachio, API version 0x84.0x5, Kernel ID 4.2 (as stated when printing out the KIP in open firmware).
I'm not 100% familiar with that codebase, but you probably want to look in the platform specific serial driver code.
Some other questions:
- Are external interrupts disabled during the polling process as well?
Yes.
- Forgive my ignorance, but is L4 multithreaded? I'm asking this because of
the minimal nature of a microkernel (which may not require multithreading given the minimal code that theoretically is there to execute).
L4 is at userlevel, but inside the kernel itself (at least the pistachio kernel), it is basically single threaded. (Well even this depends on your point of view, there are multiple different threads, but only one will ever be executing.)
Ben Leslie-2 wrote:
On Wed Apr 25, 2007 at 18:50:21 -0700, Peter Nguyen wrote:
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.
On our kernel this happens within the kernel itself. There is also a non-blocking version which allows you to perform the polling at user-level itself. I would suggest you do this which would possibly avoid the problems you are seeing.
l4-hackers mailing list l4-hackers@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#a10248378 Sent from the L4 mailing list archive at Nabble.com.
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
[Peter Nguyen]
OK. Where is this code located?
I'm currently using L4Ka::Pistachio, API version 0x84.0x5, Kernel ID 4.2 (as stated when printing out the KIP in open firmware).
There's an include <l4/kdebug.h> that defines an L4_KDB_ReadChar() and L4_KDB_ReadChar_Blocked(). However, since you're using powerpc I don't think the non-blocking version is implemented. I haven't used any openfirmware stuff myselg, but I guess it's straight forward to implement it. Look at:
user/include/l4/powerpc/kdebug.h kernel/kdb/glue/v4-powerpc/prepost.cc kernel/kdb/platform/ofppc/io.cc
You could use the arch/ia32, platform/pc99 implementation as reference.
eSk
l4-hackers@os.inf.tu-dresden.de