Development Plan Proposal for Unifying Interrupt and PCI APIs

[Thomas Doerfler]

Hello Eric,

when I got Joel right, he proposed to unify the API for PCI and 
IRQ handling. This in itself does NOT mean that the 
implementation of PCI and/or IRQ handling must be the same 
throughout a whole processor family. 

Currently we have at least two interrupt APIs, which is a mess 
concerning shared drivers (libchip ...). Currently, even the 
high level ATA harddisk driver is not portable between processor 
families, because the IRQ handling relies on 
"rtems_interrupt_catch", which is no longer available for 
i386/PPC chips.

> 
> How many time should I point out that IRQ are BSP dependent while 
> exception are processor dependent? On many processors (m68k, mcp8XX) you 
> can hardwire some IRQ, on other the IRQ is defined by soldering some 
> stuff on the extension boards, so this has to be BSP dependent even if 
> most of the time it end up being only processor...

Surely you are right, that interrupt handling depends on the 
hardware, either onchip or offchip. Nevertheless at least some 
parts of it can be defined in a board-independent way, or even 
in a processor-independent way. If I browse through the various 
powerpc BSPs, at least some of the files were  simply copied 
from eachother, without any heavy modification applied. This 
makes maintenance more painful than needed.

Some parts of the powerpc interrupt handling code might be 
unified (or at least handled in a default implementation), like 
the assembler IRQ stub, the classification of interrupt sources 
("is_cpm", "is_ppc", "is_dec"). 
> 
> I think you can also recap the expectation (requirements) we have at 
> least achieved to define last time we discussed this matter.
> 
> This includes at least :
> 	1) A void* handle, to pass per irq specific data
> 	2) A way to mask a set of interrupt while another is executing (at 
> least for (ix86, ppc)),
> 	3) Probably interrupt sharing as PCI more ore less requires it nowadays..

Yes, I think these were the major results of the last discussion 
thread.

By the way: wouldn't it be nice on the long way, to have a 
unified exception handling scheme aswell? Surely it would be 
nice to have a unified way to hook application code to certain 
exceptions (at least for error discovery and logging), have a 
standard way to get the processor registers when the exception 
ocurred and so on...

wkr,
Thomas.


> 	
> 	
> 
> -- eric

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm