Development Plan Proposal for Unifying Interrupt and PCI APIs

[Eric Valette]

Joel Sherrill <joel at OARcorp.com> wrote:

> So I guess I think the Linux design is right.  It gives a clean
> division between CPU model code and BSP code.  It is easy to explain
> and really gives the BSP some freedom.

Sure but the number of instruction per IRQ is about 20 times the really 
minimal set needed, simple IO instruction are also replaced by function 
calls and the memory requirement may even be worse. It is true that as 
if this is not a problem for libchip why start to worry about IRQs.

I, _personnaly_, would not like to pay this price for an RTOS where 90% 
of cpu time can be spent handling irqs. Now if maintenance or teaching 
is really more important than performance, I must admit I only have to 
shut up.

BTW, back to technical, allthough flexible, the linux model makes it 
nearly impossible to define IRQ masking set as the function to 
acknowledge and mask the current IRQ :
	1) Mask only the current IRQ,
	2) does not return the old mask, and that it cannot be restored 
afterwards...

So it is flexible but not sufficient for a RTOS and people are already 
complaining about that and fixing it is not trivial as no patch exist yet.

> RTEMS has very clear APIs for the most part.  The structure of BSPs is
> well documented and can be explained.  Then you try to explain the PCI
> or interrupt APIs and find out that everything is in terms of "if on
> this port, then...".  That is fundamentally bad because it undermines 
> the ability to clearly teach and understand RTEMS. You can have
> expertise on RTEMS one CPU family and be totally unfamiliar with
> another.  Not just at the hardware level but at the software structure 
> and "what does this call do?" level.

VxWorks user are accustommed to this allthough it is still the n°1 
commercial RTOS... But yes unifying API is a good thing. I worry more 
about how efficiently it will be done. Do not forget to precisely 
benchmark actual performance and compare with what you come up with when 
you will be readdy.

I think the goal to be able to distribute only a set of .o file and 
enable to write a BSP makes any trick like including ASM, redefining 
generic IRQ names really challenging. Don't you think? It will not be 
function calls but indirect function calls then...

With the BSP model, and removing interrupt connecting from non BSP parts 
this becomes a void problem.

-- eric