Development Plan Proposal for Unifying Interrupt and PCI APIs
eric.valette at free.fr
Tue Oct 26 07:52:35 UTC 2004
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 :-)
More information about the users