IPLs - One too many?

Chris Gilbert said;

Currently all interrupts are routed to IRQ, and we have to handle nested
interrupts, so we don't block clock irqs, masking and unmasking things
in the PIC, all of which is added complexity and overhead.
>
If we only need interrupts at two levels, and the hardware supports it,
we can handle all the interrupt priorities in the hardware, and bypass
quite a bit of code (and hopefully give a performance gain)

In my understanding different and incompatible rework efforts have been
made for NetBSD/arm interrupt foundation. Given this statements can
I expect those will get settled down in a single and coherent shape which
is able to adapt many ARMs?

Toru Nishimura / ALKYL Technology

Toru Nishimura wrote:
Chris Gilbert said;

>Currently all interrupts are routed to IRQ, and we have to handle nested
>interrupts, so we don't block clock irqs, masking and unmasking things
>in the PIC, all of which is added complexity and overhead.
>>
>If we only need interrupts at two levels, and the hardware supports it,
>we can handle all the interrupt priorities in the hardware, and bypass
>quite a bit of code (and hopefully give a performance gain)

In my understanding different and incompatible rework efforts have been
made for NetBSD/arm interrupt foundation. Given this statements can
I expect those will get settled down in a single and coherent shape which
is able to adapt many ARMs?

Probably end up with two. traditional type that has to nest
interrupts (eg for iomd based systems) and one for routable IRQ/FIQ lines.

Although I think it should be possible to use a common API for both
types, so we still get a common core piece of PIC handling code.

Thanks,
Chris