[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
API modification request
- Date: 01 Feb 2003 11:52:29 +0100
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: API modification request
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.