Development Plan Proposal for Unifying Interrupt and PCI APIs

[Eric Valette]

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

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

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

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

-- eric