ISR Argument Proposal Request

[Joel Sherrill]

Jerry Needell wrote:
> 
> Joel Sherrill wrote:
> > Till,
> >
> > I think that we are all as much in agreement over this as we
> > will ever be.  Let's see if I can summarize and request that
> > you write up the API changes with a list of "key" area to
> > change.
> >
> > Some issues that must be resolved:
> >
> >  + should rtems_interrupt_catch be backward compatable and
> >    this functionality have a new entry point?  I lean to yes.
> >  + should this feature be optional and conditionally compiled?
> >
> 
> Joel - Could you be more specific as to the changes to the API that are
> being proposed. I am frantically trying to evaluate the impact on the
> SPARC bsp but this discussion is moving very quickly. Exactly where in
> the API (bsp independent) would the proposed changes be implemented. As
> it is currently implemented, we do get the interrupt vector passed to
> the  ISR handler.

I was kind of deferring the development of the full proposal to Till. :)
But here goes for the CPUs other than the PPC, x86, and ARM since
they all share the same user API.

  + Version A:
     break existing API for rtems_interrupt_catch
       - void * type instead of integer vector number as argument

  + Version B:
      existing rtems_interrupt_catch stays same ..installs vector
        number as pointer argument and casts
      add new API call like rtems_interrupt_catch_with_argument
        which takes the void * pointer 

     

> > The development plan needs to have volunteers for each of
> > the following:
> >
> >   + generic change from table of handlers to table of
> >     handlers/arguments
> >   + each port's irq handling
> >   + API changes to original interrupt API, ppc, x86, and ARM
> 
> don't forget about the poor old SPARC!

It was lumped into the "original interrupt API".

> >   + documentation changes
> >   + any work break down I am missing?
> >
> >   NOTE: When you change a port, I would consider that to include
> >   getting all the BSPs modified.  Everything should still build.
> >   I regularly build all BSPs so this is somethign I can provide
> >   feedback on.
> >
> > We can't start this until we are confident all
> > the ports will get updated.
> >
> 
> -- Jerry
> 
> --
> _______________________________________________________________________
> Jerry Needell                     | Internet: jerry.needell at unh.edu
> Space Science Center/Morse Hall   | Voice: (603) 862 2732
> University Of New Hampshire       | FAX:   (603) 862 0311
> Durham, NH 03824                  |

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