Re: [pok-devel] [Discussion] IRQ handling: chaining && pending IRQs

[ Thread Index | Date Index | More lists.tuxfamily.org/pok-devel Archives ]


Hi Philip,

I think your point makes sense. Also, there is no good implementation for what you need : the good implementation would be the first one that works :)
On my side, I would say that it would make sense to have a interrupt vector for each partition so that each partition can register its callback function for each interrupt. After that, there are several questions that come into the picture such as the architecture-dependence, etc ... It seems that you are used to this type of thing so ... I would just suggest that you go ahead and as long as you do not break any existing function, go on and commit ! Your post is elaborated and shows you understand the implication of what you want so, I think you can proceed to the changes as long as there is no disturbance for the existing users.

Thanks again for your good work !


On Thu, Aug 1, 2013 at 5:41 AM, Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx> wrote:
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/