BSP_install_rtems_irq_handler API

[Joel Sherrill]

Till Straumann wrote:
> 
> VALETTE Eric wrote:
> 
> > Thomas Doerfler wrote:
> >
> > en libbsp and libcpu code/preprocessor statements.
> > >
> > > I am currently moving the helas403 BSP and PPC403/405 CPU code
> > > to the new exception handling, and I really have a split
> > > opinion on the new API. I think that some part are really
> > > nice, like to "irq_on" and "irq_off" functions in the drivers,
> > > but you are right, not passing the vector numbers to the irq
> > > function is really one design flaw among others (IMHO):
> >
> > No. You can do int by adding your own vector that push the argument and
> > then call a geberic function. In that case you pay the cost because you
> > need it but not every user that do not need it. Cost in term of
> > instruction is exactly the same.
> >
> 
> Sorry, I don't quite agree - having every driver that supports more
> than one device coding multiple wrappers or even multiple ISRs
> (as is the case for libbsp/powerpc/shared/uart.c:) is IMHO highly
> unelegant. On the other hand, passing at least the vector
> number (besides: that's what i386/shared/irq.c already does)
> hardly adds _any_ overhead because it's already sitting in a
> register anyway.

I would prefer that all IRQs receive the vector number.  

> >
> 
> -- snip --
> 
> > Starting the discussion is fine but do not try to reinvent the whell and
> > read the mailling lists archive...
> 
> Sorry if I miss something but browsing the archive from 1/1999 until today
> (search seems not to work), I only found one thread (MPC8xx interrupts,
> 10/2001) where you also state that this had already been discussed many
> times.
> 
> I'd appreciate a pointer to the thread where the pro's and con's of this
> issue (the "new" IRQ API) have been thoroughly discussed.
> 
> The reason why I bring this up is that I have to decide upon an API to
> adopt for VME interrupts (a driver for the Universe II will be available
> soon)
> and for my SVGM5 BSP (PPC G4 board by Synergy microsystems).
> 
> -- Till.
> 
> >
> >
> > --
> >     __
> >    /  `                          Eric Valette - Canon CRF
> >   /--   __  o _.                 Product Dev. Group Software Team Leader
> > (___, / (_(_(__                 Rue de la touche lambert
> >                                  35517 Cesson-Sevigne  Cedex
> >                                  FRANCE
> > Tel: +33 (0)2 99 87 68 91       Fax: +33 (0)2 99 84 11 30
> > E-mail: valette at crf.canon.fr    http://www.crf.canon.fr

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