Development Plan Proposal for Unifying Interrupt and PCI APIs

Tue Oct 26 11:22:13 UTC 2004

Eric Valette wrote:
> Joel Sherrill <joel at OARcorp.com> wrote:
> 
>>> 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.
> 
> 
> Well I'm not sure inserting asm intructions with #ifdef CPUMODEL is 
> clean and futhermore it is not CPU model but #ifdef BSP...

 From your description, I think the MIPS is conceptually inline
with the LInux idea of having a set of predefined callouts in
the interrupt processing sequence.  THose ifdefs are
not supposed to be that detail aware -- they are just handling
the unfortunate variety of differences on MIPS CPU models
in regards to registers and bit locations.

The m68k is the same way.  Instructions available differ and
the ifdef's are for that.  None of it is about PICS.

>> 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.
> 
> 
> Not only that but all the knowledge to mask and ack the IRQ before 
> calling the handler(vector, handle) and this has to be done at the very 
> beginning of the ISR code as the interrupt has still to be masked at CPU 
> level. Saving and restoring the interrupt controller mask is also 
> specific so you will go back to a nearly totally specific IRQ code when 
> the only generic part is the interrupt stack switch and the call to the 
> executive to make rescheduling... Linux does indirect function calls to 
> handle that but there are not less than 5 different functions to 
> implement per BSP and of course they are stored in table for each irq... 
> I really do prefer to rewrite 15 lines of asm code but maybe its because 
> I'm not affraid by ASM coding...

I'm not afraid of ASM coding either.  I do have an extremely high 
distaste for duplicated, hard to safely modify code that I HAVE to
test to know it is right.  This is a maintenance issue.  People come
and go and we still manage to keep the BSPs going for years in between 
reports of them working.  That's because you can review C with some 
confidence of being right.

RTEMS has a design goal of minimizing assembly language to ease 
maintenance.  It also has the design goal of sharing as much code as 
possible across as many platforms as possible.  That is balanced with 
trying to be as lean and fast as possible.

We have been easing the burden of writing BSPs for years and the Linux
model looks easy to explain to me.  I tell you to write N functions with 
these prototypes.  They are expected to do this and here are some 
examples.  Right now, I have to tell you that there are 4 ways of doing 
it and 3 of those require the ability to right assembly language fairly 
well.  I have to couch everything in "if you are on this CPU, then the
name of the routine is this" and "if you are on this CPU, you don't get 
a vector number".  I want all that to end.

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.

So I guess I am coming down in favor of having the CPU dependent
code invoke BSP/IRQ specific routines at predefined points in the
interrupt processing sequence.

> Try _really_ to make asm include for two ix86 BSP one with only a 8259 
> and one with two (actual code) and one with APIC support to see what I 
> mean. I'm rather sure you will be convinced...
> 
>  >  That seems to be what happened every time
> 
>> in the past -- we got side-tracked.
> 
> 
> My view of the past discussion is that Till did not take care to define 
> the requirments before proposing an API and that, doing that, we were 
> discussing on sand fundation. Furthermore he missed at least some of the 
> issue for a correct API :
>     1) Interrupt masking set,
>     2) defining precisley what should be donne by "generic irq handling" 
> code for a BSP (e.g on ix86 masking the current IRQ at 8259 level, 
> acknowledging it, reenabling interrupt at processor level), and what is 
> left to device irq driver. If you do not do that, even if you manage to 
> have a generic way to connect irq(vector, handle) the next line will 
> start with at tons of #ifdef code to really enable the interrupt at PIC 
> and then at controller level)
>     3) exporting the On/Off/IsOn functions so that code with no 
> knowledge of the hardware can temporarily disconnect specific interrupts 
> (this is a requirement for real world benchmarks, software debugging, ...)

Part of defining the API is going to be defning the 
structure/information that is associated with each interrupt source.  I
am not arguing against this.

> So after much hot/flaming debate, the discussion lead us nowhere beside 
> "please identify the requirement first" so that we can _effectively_ 
> discuss the merit of API compared to requirements... Once we managed to 
> identify the requirements, the discussion about API vanished because we 
> where all upset/exhausted...

And although I didn't say it.  I want to unify the API a small step at a
time.  Agree on the header file name, one API routine, etc, etc

> And having the same API was not identified as the most important 
> requirement by developpers but by maintainer if I remember correctly but 
> I agree it is important but not for implementaing libchip as only the 
> BSP has the knowledge of IRQ :-)

No. It is really worse than that.  That is just the most visible shared 
code that depends on things being similar.  If there were no shared code
impacted it would still be needed.

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.

Teaching the class this past time is what drove me over the edge.  I
want to teach a single way of doing things.

THis is why it MUST be fixed.

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