Re: [pok-devel] [Discussion] IRQ handling: chaining && pending IRQs |
[ Thread Index | Date Index | More lists.tuxfamily.org/pok-devel Archives ]
Hi,
currently the interrupt handling does not support two features,
necessary for my GSoC project: interrupt chaining and delivering pending
interrupts.
If one partition registers a handler for IRQ 0, then no other partition
is able to register a handler for the same interrupt line.
As I want to run several RTEMS instances in different partitions on POK
one day, I need to be able to pass the clock IRQ on to every partition
needing it.
I come from the L4 microkernel world and are used to stuff like that,
but it might introduce an overhead you are not willing to pay for in the
embedded world. I appreciate a lively discussion about this change.
I have put together a blog post, with a little bit of source code.
http://phipse.github.io/rtems/blog/2013/07/09/how-late-is-it/
Here is a summary of the post.
I propose a meta handler, registering the IRQ with POK. One meta handler
per IRQ vector. The meta handler is intercepting the current
registration process and stores the received handler in a array indexed
by the current partition number. If several partition want to acquire
the same IRQ vector, their handlers are stored in the array and get
invoked when the IRQ fires and they are currently running.
If they are not running the IRQ is stored in the pending array, also
indexed by the partition number. When the scheduler changes partition it
needs to check for pending interrupts for the selected partition on
every meta handler and deliver them.
Open questions: Where to store the meta-handler table.
Cheers,
Philipp
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |