[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISR Argument Proposal Request
- Date: Tue, 04 Feb 2003 12:46:23 -0600
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: ISR Argument Proposal Request
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