Development Plan Proposal for Unifying Interrupt and PCI APIs

[Joel Sherrill <joel@OARcorp.com>]

Eric Valette wrote:
> 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.

The IRQ code is not going to be rewritten to be like libchip.  It will
NOT use indirect calls for IO accesses.

> 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.

We won't be replacing simple IO instructions wholesale with callouts.
The worst that could happen is that BSP will get called in response to
a CPU interrupt and then it does whatever it wants.  The MIPS uses
this model and the BSP gets to pick the routine that is invoked as
soon as RTEMS saves some registers and does its required interrupt
entry code.


> 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.

Then wherever we land needs to be address that.  :)

>> 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.

Yes.

> 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...

Even when RTEMS is able to be distributed as a set of .o's, it will only 
be the poirtion now in cpukit.  It is expected that the BSP developer
will want access to the libcpu and libbsp code and will compile that 
themselves.

The .o's are only allowed to know the distinction between the
CPU cores -- not particular CPU models or BSPs.


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

It can go in libcpu and will still be available to be compile time 
extended by the BSP.

Ditto for libchip if we change the register access model.

There is no plan to pre-compile device drivers since you almost always 
want to modify or debug them.


> -- eric
> 
> 
> 
> 
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985