[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Tue, 08 Jan 2002 10:27:27 -0800
- From: strauman at SLAC.Stanford.EDU (Till Straumann)
- Subject: BSP_install_rtems_irq_handler API
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
or at least
vs. the current implementation:
> > 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:
etc. IMO, this is clearly a _lot_ more unelegant, inefficient and less
than having the dispatcher passing at least the vector as an argument...