Development Plan Proposal for Unifying Interrupt and PCI APIs

[Eric Valette]

Joel Sherrill <joel at OARcorp.com> wrote:
> This gets mentioned repeatedly but every time one of these drivers is
> benchmarked, it performs well.

Sure but it should perform even better : the IRQ API of thoses systems 
being more complex and more time consumming, if it perform the same now 
that I'vebeen optimising IRQ path to detriment of functionnality, 
restore the functionnality and then redo the benchmarks...

> The use of callouts for writing registers is equivalent to the
> use of overloaded, not inlined members in a C++ class. 

Be more concrete to help people to understand : imagine you have, to 
read 10 registers to hanlde an interrupt, using libchip, you will 
replace 10 asm instruction (say inb,inw,inl or even better with IO 
mmaped access) by 10 function calls. I maintain :
	1) This is not really efficient,
	2) This could be doen the other way round without changing the purpose 
of libchip like it is done on most OS...

I will not even mention the fact that LynxOS has MMU support which
complexify drivers code quite a bit...

> Either structure still puts the bulk of the ISR in portable space.

Frankly joel, the problem for RTEMS today is not lacking a portable IRQ 
layer, the problem RTEMS is facing today is to get more drivers for more 
generic things that are required for embedded devices today like :
	1) Useable disk drivers,
	2) USB (not only slave),
	3) Video,

Do you imagine having to make RTEMS work on a telephone or an MP3/Video 
portable player with a disk?


> At some point, everyone is an old developer (even myself) so I hate
> to point fingers. 

The intend was not to point fingers just to explain how things ended up 
being the way they are from my personnal point of view.

> There is nothing to stop the generic driver from having help from
> the BSP in the interrupt service routine.

Practically there is but until you try completely you will not be 
convinced I guess. I recall VxWorks has a different API on different CPU 
familly and Linux has totally different implementation for the same API. 
Do you think they have done this without many other people tring to make 
the code converge again?

-- eric