Re: Emulating the use of Global VxWorks Variables in OSI

[Matt Rippa <mrippa@gemini.edu>]

Hi Andrew,

That's encouraging. Indeed, devSymb is the better approach and minimizes the impact on our design.

I'll talk to you more in a PM. 

Thanks,

Matt

On Jan 20, 2017 11:12 AM, "Andrew Johnson" <anj@aps.anl.gov> wrote:

Hi Matt,

On 01/20/2017 02:00 PM, Matt Rippa wrote:
> I have a telescope system (our 8 meter primary mirror) which employs
> DTYP=vxWorks Variable in a ubiquitous manner.
>
> In rtems this is not possible

I will allow that the existing device support code won't compile or work
on RTEMS, but I'm not sure that you have to throw out the approach
completely.

The "VxWorks Variable" support was renamed to devSymb support, and has
been discussed on tech-talk a few times, look for "symb device support"
and "devsymb" in the tech-talk search box. I think the latest work I did
on this was described here:
  http://www.aps.anl.gov/epics/tech-talk/2007/msg00130.php
but that code was never finished or published — I'd be happy to send it
to you if you want to take a look though.

However the use of epicsFindSymbol() should be replaced or augmented by
registering variable names in DBD file "variable" statements and looking
up their addresses at runtime using the libCom registry. That may not be
possible with the existing IOC code because only the iocsh code
currently has access to the list of registered variables, but I'd be
willing to accept minor modifications to Base to fix that.

I'm hoping Gemini will be willing to work on making devSymb functional
on all architectures, which this approach would do.

- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon