Relating rtems_symbolic_irq_name to vector number

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > 
 > > Actually the problem is worse.  I can get the vector from the card no
 > > problem and get the interrupt set up- the existing code woks ok for
 > > that.  I also found the PPC vectoring code which makes sense, but the
 > > handlers are not passed any parameters... not even the vector.  I
 > > suppose a good reason was given at some point for lossage like this,
 > > but its quite annoying.  I presume its also why the unit # has been
 > > hardcoded in the dec and fxp drivers.  Is there any reason why I
 > > shouldn't tweak the vectoring code to pass the irq #- it won't cost
 > > but a couple instructions and will make the vectoring much simpler.
 > 
 > You are in the exact position where a handle could help a lot. So either 
 > you hardcode or change the BSP implementation to add the void*
 > 
 > NB : if you request it politely, I can issue a temporary patch waiting 
 > for Till proposal...
 > 

Sorry if I came on too strong- it was a shock to find something like
passing the interrupt vector to be specifically not
supported... Anyhow, a simple re-cast of the function pointer at
call-time to one that takes an int argument, then just adding the
vector parameter to the call works fine.  It also doesn't require
messing around with all your other existing work- so I'm not stuck.
Basically, only the pci interrupts get the vector passed to them and
nothing else is affected.

Gregm