API modification request

[Joel Sherrill]

Laurent Guerby wrote:
> 
> Till Straumann wrote:
> > OK, let's recap the discussion:
> >
> > Me: I'd like to have the ISR passed a user argument,
> >     i.e. not
> >
> >        typedef void (*rtems_irq_hdl)(void); /* current */
> >
> >     but
> >
> >        typedef void (*rtems_irq_hdl)(void *arg); /* proposed */
> 
> Stupid question, why not both with configuration time option
> (with standard macro for #ifdef...) to activate support for the second?
> 
> typedef void (*rtems_irq_hdl_with_arg)(void *arg);
> 
> API is upward compatible,
> performance is unchanged if the feature isn't used or not available,
> but of course it adds one more option to a growing list.
> 
> (I've no idea of how often type type appears in the API
> or its implementation.)

This isn't a bad idea and is fairly close to an existing CPU option.
We already have an option to indicate that a port passes the ISR
vector number to the handler.  Some ports invisible pass a first 
argument.  Since the vector number is required for RTEMS to be able
to invoke the ISR, this is a nearly zero cost option.  All it would
take is ensuring that the data that is already available at the
time of the call is passed per CPU calling conventions.

Passing a (void *) requires that a lookup table be maintained and
could easily be layered onto the primitive feature of passing a vector
number.  So if the user wanted no data or the vector number call the
primitive ISR intallation routine.  If they want to be passed a void *,
then call a wrapper for that which ends up installing a generic
ISR handler that looks like this:

  _ISR_VOID_PTR_WRAPPER(rtems_vector_number vector) {
    (*ISR_WRAPPER[vector].handler)(ISR_WRAPPER[vector].data);
  }

The downside to this approach is it adds more memory overhead for
the 2nd subroutine call and does 2 extra look ups.  On the plus side,
it does not require any significant modifications to existing ISR code,
and is easy to ignore if you want lower overhead.

Another approach to adding a conditional feature.  

> --
> Laurent Guerby <guerby at acm.org>

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