Development Plan Proposal for Unifying Interrupt and PCI APIs

[Eric Valette]

Thomas Doerfler wrote:

> Currently we have at least two interrupt APIs, which is a mess 
> concerning shared drivers (libchip ...). 

Well do not throw libchip in because I will have to tell some facts 
about how the chosen design has bad influence on ist related to 
performance...

NB:  put everything I say as conditionnal as I have'nt looked at the 
code for months. I'm currently more interested in Hard/Soft Real Time 
with Linux as people are more inclined to pay me for that than for RTEMS 
knowledge...

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

Granted. But if you look at the i386 BSP there is (was) a shared 
repository that contained only one -single_ copy of the sources... So do 
not mix the following things :
	1) IRQ are by nature BSP dependent,
	2) Because of legacy systems, it is possible to have some
	part of the code shared and it is also natural to expect to have global 
naming. But do not even think a second that because of having a global 
naming, you will be able to have a single driver... It just does not 
work because the interrupt routine itself will end up full of ifdefs...
	3) This technic was not used on PPC because too much BSP where 	present 
and no active maintainers were availliable at the time of rewriting 
leading to the messy old/new execption model,
	4) You can make it as generic as possible provided it does _never_ 
prevent to have a BSP specific implementation of IRQ

Even Linux gave up having a single IRQ implementation allthough things 
are currently converging again with great pain,

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

Sure. It is even necessary to hook debuggers in like rgdb which was my 
initial goal.

-- eric