RE: SENS stack vs EPICS

[johill@lanl.gov (Jeff Hill)]

Bill,

> 
> A while back you wrote:
> 
> > This is a known problem with Channel Access and the new "SENS"
> > IP kernel from WRS.  They (WRS) are defining a macro with the
> > same name as one of the fields in a data structure used throughout
> > the CA source code.
> 
> > This problem can be avoided if the "SENS" option is not specified
> > when installing Tornado.
> 
> Perhaps you have said more on the subject, but I couldn't find it in
> the archive.
> 
> In order to get a version of vxWorks for the mcp750 cpu (which we're
> using in our compact PCI efforts) which will allow us to use a
> reasonable
> amount of cPCI address space, we're forced to move to vxWorks 5.4.  And
> vxw_5.4 doesn't provide an option to use the old IP stack.  "SENS" is
> the only option, AFAIK.
> 

It turns out that this problem is worse than it initially appears.
I have already changed the 5 letter structure member name that their
macro collides with, but there is this additional problem that none
of the network interface query ioctl() stuff is working. The result is
that the EPICS_CA_AUTOT_ADDR_LIST=YES related code in Channel Access 
fails. The symptoms of this are hard to miss in IOCs that are CA client's. 
The effect (no beacons) on IOC's that are CA servers is more subtle.

I have a TSR open with WRS.

Jeff

> In order to get a version of vxWorks for the mcp750 cpu (which we're
> using in our compact PCI efforts) which will allow us to use a
> reasonable
> amount of cPCI address space, we're forced to move to vxWorks 5.4.  And
> vxw_5.4 doesn't provide an option to use the old IP stack.  "SENS" is
> the only option, AFAIK.
> 
> No doubt this is a (the?) major value-added feature of vxw_5.4 & Tornado
> 2.
> 
> Is there a patch or some work-around available?  How horrible is it
> going
> to be to fix this?  Any suggestions besides, "Don't do that!"?
> 
> TIA for your suggestions!
> 
> -- 
> 
> 
> -bill
>