Development Plan Proposal for Unifying Interrupt and PCI APIs

[Joel Sherrill <joel@OARcorp.com>]

Eric Valette wrote:
> 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 agree that it is not the most run-time performance efficient way to do 
it.  My contention is that it works and is simple.

And even if you don't like the chip register access method, that has
absolutely nothing to do with the proposals on the table.  You can
replace all the indirect calls with macros and you are still stuck
with code that has ifdef's because we don't have uniform APIs for
PCI or basic interrupt issues.

I am not disputing the fact that there may be a base common API
and additions on some CPUs to take advantage of features. I just
know that there is a common ground we are missing.

My development plan proposal was specifically intended to
avoid getting sucked into side issues.  The libchip
use of indirect calls for register accesses is an
independent issue which has nothing to do with unifying the
interrupt and PCI APIs.  It meets the goal of being the same
on all CPUs.  If there is a better and still uniform way of
doing this, then we can switch to that independent of
cleaning up the APIs.

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

My point was that if the four OSes mentioned all benchmark
their device drivers with indistinguishable performance, then
the hardware is the limiting factor.

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

Right now, there is a useable hard disk driver.  I don't know
specifically what criticism you are making.

USB is still an issue.

There are video addons but RTEMS does not have high end graphics 
support.  If you are happy with MicroWindows, PicoTk, etc. then
RTEMS meets your needs.

FWIW the same comments could have been made before there was networking,
any filesystem support, etc.  This is open source.  It evolves and 
grows.  Those functionalities will show up as people volunteer or
sponsor the work.  I would have an ulcer if I tried to worry about
those things. :)

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

I am not trying to blame anyone for anything.  I just want to find
the common ground and move forward.  If we uncover other things we
want to change along the way, great.  But there is a known issue
that the same functionality has different APIs on different CPUs
and it doesn't have to be that way.

Performance improvements are independent.

RTEMS evolve.

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

I think this is where we are.  We have different APIs and we are trying 
to converge them.  I want to repeat -- I am not pushing for a single
implementation -- just as close to a uniform API across all ports as 
possible.

I am not even pushing a single location for the implementation inside 
the source tree.  It could be in score/cpu, libcpu, or libbsp.  I don't
care as much about that as I do having a unified API with the 
possibility of additions on certain CPUs.  But those have to be 
minimized and justified.

I do want to get ISR(vector, void *context) before we are done.


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