The eCos, QNX, ChorusOs irq handling API

[Sergei Organov]

Valette Eric <eric.valette at free.fr> writes:
> Someone suggested to look at other IRQ handling API. I already send a
> pointer to the ChorusOS irq handling API, here is the eCos API and the
> QNX API.
> 
> <http://sources.redhat.com/ecos/docs-1.2.1/ref/ecos-ref/the-api.html>

That's a wrong reference, IMHO. Unlike eCos, RTEMS doesn't have special API
for device drivers, so here is a better reference (besides, it points to the
latest docs, not 2 years old ;-):

<http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.9.html#pgfId=1088792>

> eCos : Nothing I would recommand.

Interesting distinction between interrupt create/delete, interrupt
attach/detach, and interrupt configure. Note how the storage for interrupt
descriptor is provided by the caller of the "create" routine thus allowing
BSPs (HALs in eCos terminology) to don't care of storage.

Exceptions handling and interrupts handling are explicitly separated.

DSR is not applicable to RTEMS as RTEMS's ISR is simultaneously a DSR.

VSR in eCos terminology is roughly equivalent to the raw_interrupt_handler in
the terminology of (some?) RTEMS BSPs. Maybe it's worth to have raw interrupt
API in the RTEMS as well.

There also is an "cyg_interrupt_acknowledge" routine to be called from ISR
handlers when necessary (it could be no-op for some platforms).

The API seems to be complete and rather simple. Overall, that's roughly what
I'd like to see in the RTEMS.

> <http://www.jaluna.com/doc/c5/html/ManPages/hman9dki/svIntrAttach_x86.9dki.html>
> 
> The one I prefer. I wrote it years ago and RTEMS one can be seen as a
> second iteration... API is at least still processor dependent :-)

Very clever. Are you arguing in favor of RTEMS doesn't need any processor
independent ISR API at all?

I'd suggest to develop general processor/platform independent API every BSP
should adhere to and *only then* explicitly allow BSPs to define their own
additional routines at wish (e.g., for optimized ISR enabling/disabling,
etc.).

> They have indeed added the void* argument, suppressed the isOn routine
> (probably because one can assume that irq is enabled if a vector is
> connected which is not always true?)

Probably because it has never been called? At least I haven't found any
calls of this routine in the RTEMS PPC BSPs.

It seems that the next logical step is to remove on and off routines as well
:-)

> and I would follow them...

You definitely are free to follow whoever you wish, but I'd not adopt it for
RTEMS interface unless you clearly explain what are the advantages of this
on/off/isOn interface complication compared to the approaches the rest of the
world takes. For me it seems that you, as the author of the concept, are just
too biased towards it.

It'd be also fine to know if anybody else thinks that these on/off/isOn
pointers are "a good thing" worth adding to the general RTEMS ISR API.

> 
> NB : if someone has a pointer to VxWorks API, I would like to get it
> because I have hunted google and altavista but found only part of it
> inside FAQ but no official doc.

I don't have a pointer, but I have a book (1992 year -- rather old) called
"VxWorks Programmer's Guide" that has (incomplete) description of the
interface. If you wish, I can type a quote from the book here, but basically
everything is as usual. ISR takes additional argument specified at interrupt
connection time. Nothing similar to on/off/isOn, so it seems that you are
still alone with your invention :-(


-- 
Sergei.