Re: intConnect vs ipmIntConnect vs devConnectInterrupt

[Andrew Johnson <anj@aps.anl.gov>]

Bill Brown wrote:
> 
> Is there any reason why ipmIntConnect() couldn't call devConnectInterupt()
> instead, thereby simplifying debugging and perhaps book keeping?

When I originally wrote the IPAC support layer for Gemini & UKIRT one of
the requirements was that it could be used independent of EPICS.  This is
why my carrier drivers don't use the facilities of devLib such as
devConnectInterupt() but call the vxWorks routines directly, although
there's no fundamental reason why they couldn't.

I'm now in two minds about this, but on balence it probably ought to
happen.  The results then become useless to anyone outside of the EPICS
consortium, but I'm not sure if there are many of those left now (although
I did change the licensing not long ago to use the GNU LGPL when
approached by someone from outside).  The advantage of switching is that
from EPICS R3.14 onwards a VMEbus carrier driver that uses devLib can run
on any OS that devLib supports.

There is one alternative that I suggest you might look at though which
avoids having to change the carrier drivers - if devLib provides a
function that you can call to get a free vector number, you could use this
in your startup script to provide the vector number argument to your
module initialization function.  In many ways I prefer this; its much
better to request a free vector number than the "try this one to see if
it's available" approach - the former only fails when there are no free
vectors left.  If devLib doesn't yet provide such a function then perhaps
it should [don't ask Jeff to write it for you though, he's very busy
working on CA for 3.14].

> I also see that drvIpMv162.c doesn't seem to support this entry point.
> Does this mean that IP-generated interrupts cannot be supported when
> using the mv162 (or '172?) as a carrier?

No, the command table for the mv162/172 carrier has a NULL in the
(*intConnect)() position, but this tells ipmIntConnect() to call
intConnect() directly.  It doesn't mean ipmIntConnect() is not supported. 
When you're writing IPAC module drivers you should *always* use the
ipmIntConnect() function or you'll no longer be portable between carrier
boards.

- Andrew
-- 
Every great idea appears crazy to start with.