Development Plan Proposal for Unifying Interrupt and PCI APIs

[Joel Sherrill <joel@OARcorp.com>]

Eric Valette wrote:
> 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...

This gets mentioned repeatedly but every time one of these drivers
is benchmarked, it performs well.  I know that at least two of the
drivers have been benchmarked against VxWorks on the same hardware
and performed the same.  [That comparison has been performed on two
different CPU families and two different drivers.]  One of the
libchip drivers has been benchmarked against VxWorks, Linux, and
LynxOS on the same hardware with no measurable difference between
them.

The use of callouts for writing registers is equivalent to the
use of overloaded, not inlined members in a C++ class.  Sure
you could save a few cycles by using BSP dependent macros and
recompiling the driver but that wasn't the goal.  Also this avoids
name space issues -- some systems use the libchip with on-baseboard
ports, on-mezzanine, and off-board chips  and all use the same
driver.

The other issue is the conditional compilation for differences
in the PCI and interrupt APIs.  That is what I want to eliminate.
There is no reason the PPC should have:

BSP_pciFindDevice( PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21140,
                           unitNumber-1, &pbus, &pdev, &pfun)

while the x86 has:

pcib_find_by_devid( PCI_VENDOR_ID_DEC, deviceId, unitNumber-1, &signature)

This difference is just justifiable.  There are similar places
in the multiple interrupt/exception APIs.

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

Quite possible and likely even.

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

Sometimes this is true.  Not always and even when there is a BSP
dependent section, it can often be generalized into something like
do BSP specific something at entry or exit.

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

There is nothing to stop the generic driver from having help from
the BSP in the interrupt service routine. THis has the structure
of libchip driver making callouts.

Or from having the BSP provide the outer ISR code and invoking
helper routines in libchip to get data from it.  Some boilerplate
structure the BSP is supposed to use.

Either structure still puts the bulk of the ISR in portable space.

I am more concerned about driver functionality and structure than
about squeezing the last cycle out of it.  I have come to be a
believer in fast enough and correct over writing in assembly language
and never really being sure about correctness.  CPUs are very
fast these days.  libchip is being used primarily for devices which
are so smart they do all the work anyway with bus speed limits
being the limiting factor (network), very infrequently (RTC) so
performance is not a factor, or serial ports which are in fact
highly optimized drivers ignoring the callouts for register
accesses.  All is hard code to get correct so having a network
or serial driver in minutes is the goal.

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

I have been killing BSPs and old ports on the development tree.
Some of this will help out here as well.

At some point, everyone is an old developer (even myself) so I hate
to point fingers.  If I can't find an active maintainer or hint
of use on a BSP, it is quite likely to disappear in the not so
distant future.

>     4) You can make it as generic as possible provided it does _never_ 
> prevent to have a BSP specific implementation of IRQ

There is nothing to stop the generic driver from having help from
the BSP in the interrupt service routine.

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

Not a problem.  Let's just be clear from an implementation point what
the difference in the processing is.

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