API modification request

[Ralf Corsepius]

Am Fre, 2003-01-31 um 22.36 schrieb Joel Sherrill: 
> Till Straumann wrote:
> > 
> > Hi.
> > 
> > You may have noticed that I'm in a militant mood today
Using the word "militant" while arguing with an "Old European" in
parallel is a very delicate thing, these days. ;)

> > and so I dare bringing this up again:
> > 
> > I propose to change
> > 
> > typedef void (*rtems_irq_hdl)(void);
> > 
> > to
> > 
> > typedef void (*rtems_irq_hdl)(void*);
> > 
> > i.e. have the option to pass an argument
> > to the interrupt handler.
> > 
> > I want to convince people (especially in the EPICS) community
> > that it's easy to port software, essentially from vxWorks, to
> > RTEMS. Porting drivers is significantly complicated by the fact
> > that an ISR cannot be passed an argument under RTEMS (under vxWorks,
> > they can).
> > 
> > The speed argument heard before is IMHO, ridiculous:
> > On the PPC and X86 it takes 1 (ONE) instruction more to do
> >   p->hdl(p->arg) instead of p->hdl() as the necessary pointer
> > is already in a register). Contrast this with the headache
> > and space requirements of writing countless wrappers.
> > I'm positive we can identify some superfluous instructions in the
> > ISR calling code to trade in for the handler argument ;-)
> > 
> > As far as I can see, the new semantics would be backwards
> > compatible (getting compiler warnings at most).
> > 
> > Joel, Eric, what's your position on this?
> 
> I have never been opposed to it on technical grounds 
I am not really opposed, however am reluctant for 2 reasons:

1. If passing an argument to ISRs, I would prefer not using void*, but
an opaque/abstract type instead (isr_arg_t*).


2. Such an isr-argument is not supported by on-board means of all CPUs.
Eg. for the SH1, passing an argument is not supported by the CPU,
therefore looking up ISR arguments would imply overhead.

=> Though you might gain something on some CPUs, you loose on others.

> -- only 
> on consistency grounds.  All ports should support it. That
> raises the implementation stakes a bit.
Yes, it would be incompatible.

Ralf