Development Plan Proposal for Unifying Interrupt and PCI APIs

[Joel Sherrill <joel@OARcorp.com>]

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

In this case, you are right the BSP does have to be aware of things.
I do not think it is perfect but the mips model is in the right 
direction to me.  It shares a LOT of assembly code with a
distinct point to insert a CPU model or BSP specific routine.

In the case above, the procedure to get from hardware ISR to
the handler for a particular x86 vector is well-defined.  It
is what happens at that vector which is BSP specific.

But again, I am not as concerned about the implementation as I am
about the relative small API used to attach interrupt handlers.

NOTE: I am concerned about the implementation but that is secondary
to having a more common API.  :-)

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

I'm not as much trying to justify it as trying to keep any design
issues in how libchip does register access distract us.  I took off
my coder hat and put on the rarely used and very dusty project
management hat.  I just want to really make progress on the unified
API at this point and I am likely to politely redirect any conversation
that distracts from this.  That seems to be what happened every time
in the past -- we got side-tracked.

So the focus is on single issue at a time.

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

I don't know what the magic is but it can't be that far off... this
product uses it

http://www.rtems.com/phpwiki/index.php/TCB-2

One of my goals for Bochs was to have a standard platform that we could
easily and regularly check out standard add-ons.

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

Did this get associated with a PR or are we depending on my nearly
infinite capacity Inbox? :)

It is time to dust it off again.  I am trying to be focused and
stubborn.  I think Till has this capability on the PPC.  With
some push, it can be spread across the others.

--joel