BSP_install_rtems_irq_handler API

[Till Straumann]

VALETTE Eric wrote:

> Till Straumann wrote:
>
> > Hi all.
> >
> > I realize that more and more BSPs are migrating to the
> > new interrupt management API. Has the design
> > of this new API (which IMHO is rather clumsy) ever
> > been thoroughly discussed?
>
> The API is the result of a European RDP project to define a complete
> RTOS API. It is a minimal merge of what other RTOS implement without
> placing the cost high for simple feature.

Well, I can't really see the "high cost" of

rtems_hdl_tbl[irq].hdl(rtems_hdl_tbl[irq].usrArg);

or at least

rtems_hdl_tbl[irq].hdl(irq);

vs.  the current implementation:

rtems_hdl_tbl[irq].hdl();


>
> >
> > I believe that it is a major design flaw not to pass
> > the ISR any information (user pointer or at least the
> > vector number). Without ugly hacks, it is impossible
> > for a driver to support multiple instances of a device
> > or for BSPs to support interrupt sharing.
> >
> > What was the reason for making ISRs
> >
> > typedef void (*rtems_irq_hdl)           (void);
> >
> > and is there still a chance to change this API??
> >
> > Regards
> >
> > -- Till.
> >
>
> This has been discussed on the mailing a good 10 times. If you are too
> lazy to code a simple redirector that calls a generic function with
> vector included, do not ask everyone to pay for passing an argument that
> most of the time is never used...

I'm sorry - I don't understand your 'redirector' idea. The only way I could

imagine doing it is by having a redirector routine for each vector:

void redir_hdlr1(void)
{
   generic_hdlr(ARG1);
}

void redir_hdlr2(void)
{
  generic_hdlr(ARG2);
}

etc. IMO, this is clearly a _lot_ more unelegant, inefficient and less
flexible
than having the dispatcher passing at least the vector as an argument...


-- Till