Development Plan Proposal for Unifying Interrupt and PCI APIs

[Eric Valette]

Joel Sherrill <joel at OARcorp.com> wrote:

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

I do not argue that either. I just prefer to let the BSP connect the 
handler to the IRQ because it knows things the common layer will never 
know like the real vector or how to acknowledge the IRQ properly.

In your proposal how do you handle a ix86 BSP that connects timer to IRQ 
1 on a 8259 and the another ix86 BSP to IRQ 6 (and even possibly with a 
different interrupt controller than the classical 8259 emulation)?

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

Right. It's no me that is trying to justify it. I just said that libchip 
make questionnable design decision and that I hope that the same 
architecture will not be used for IRQ... Having a driver library is fine 
provided it is not the root cause of some of the problems by trying to 
connect IRQ itself. Providing a routine that should be called with the 
relevant parameter and precise definition of interrupt status (e.g 
processor enabled, a set of other interrupts enabled, current IRQ 
masked) is good enough.


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

Since when nobody checked that microwindows can compile with RTEMS?

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

Yes but if the amount of work required to port it to a real device grows 
too much, then alternatives may be chosen...

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

Fine you know I already submitted patches for Ix86 to have it at least 
twice :-)

-- eric