Re: devSymb

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

Hi Rolf,

Rolf Keitel wrote:
> I am new to 3.14. Has anybody done the equivalent of the VxWorks 
> devSymb   for Linux, which would allow records to access global 
> variables from the device support level?

I started looking at making devSymb portable in 2004 (the vxWorks code 
for 3.14 is in the EPICS CVS repository and downloadable from the 
download/modules page), but I didn't get very far with it at the time.

To get the symbol address in a portable manner I'd require that you 
register all your variables within a DBD file.  We already allow the 
'variable(name,type)' syntax in the DBD file parser, you'd also have to 
annotate the variable source using 'epicsExportAddress(type,name)'. 
This was provided to allow iocsh to read and set such variables.  I'd 
then change devSymbFind.c to do the same lookup that iocsh does in order 
to find the symbol address if the call to epicsFindSymbol() fails 
[that's the new OSI name for symFindByNameEPICS() BTW, but maybe it 
should do that lookup itself.  Maybe even the Linux version of 
epicsFindSymbol() should use the dlopen()/dlsym() routines instead?].

I started to think about the storage type of the variable, and how that 
maps to the record type, and at this point I stopped because I didn't 
want to have huge numbers of device support types for every combination 
of int/short/long/double vs Ai/Ao/Li/Lo/Mbbi/Mbbo/Wf record.  However I 
think that was a bit of a red herring because the DBD variable() 
statement only supports int and double at the moment anyway.

I'd be happy to see an updated portable version of devSymb if you do 
come up with one; if you find you need any changes in base to facilitate 
that just let me know.

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey