API modification request

[Chris Johns]

Joel Sherrill  wrote:

> This why I think a trampoline function is the better way to go.

I am wondering if performance is being quoted only in reference to the supercore 
distpatch overhead, and maybe not in the whole context of interrupt processing.

<aside>

A weaker argument for, but one which needs to be added is a quick check shows 
vxWorks, NetBSD, FreeBSD, Linux, eCos (provides vector and data) all seem to have a 
pointer type argument. We may come up with all sorts of ways to make this work with 
trampoline functions or what-ever but these all require special RTEMS knowledge. When 
do I use a trampoline, what libchip drivers need which glue etc. I wonder if a 
simpler API for RTEMS along the lines of what other OSs provide is worth considering.

</aside>

> Ensure that all ports pass a vector number as the first
> argument.  Write a generic set of trampoline code that takes
> care of the folks who want the advanced feature of a void * pointer.
> It takes (number_vectors * sizeof(void *)) memory to keep up
> with those pointers.  I hate to see the minimum memory requirements
> creep up yet again.

IMO memory usage for low memory footprint targets is an issue. How to provide both is 
something I do not know and comes back to what Ralf meantioned.

> The trampoline code seems rather generic and the rest is just a matter
> of making the the ISR vectoring code always passes the vector
> as the first argument.  Then everyone wins.

Is this tampoline user implemented glue or a score thing ?

Looking at the libchip code to see what is currently done I find:

The cs8900.c requires a void*, same with the i82586.c driver (came from NetBSD 
assuming a void* be provided). The glue logic provided by a user needs to translate 
the vector to the device structure.

The dec21140.c does not seem to handle more than instance (plus has references to 
i8259 which should not be in a libchip driver, grrr). Same with if_fxp.c which has a 
comment to stating this needs to be fixed. Maybe a void* argument would help ? :-)

The sonic has a loop to scan each device when more than one device is enabled. That 
has got to hurt performance and I would trade memory for this loop any day.

The mc68681.c serial driver has a loop to find the device structure from the vector. 
Same with the ns16550.c. Also the z85c30.c has the loop.

The point I come back to is performance is focused on the score dispatch, yet we have 
drivers that are scanning lists to locate a *void within interrupt handlers.
-- 
  Chris Johns, cjohns at cybertec.com.au