Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Replacement for dbGetPdbAddrFromLink ?
From: "Dunning, Michael" <mdunning@slac.stanford.edu>
To: Michael Davidsaver <mdavidsaver@gmail.com>
Cc: EPICS Tech-Talk <tech-talk@aps.anl.gov>, "Condamoor, Shantha" <scondam@slac.stanford.edu>
Date: Tue, 15 Aug 2017 10:52:15 -0700
Hi Michael,
Thanks for the background info.  In my case, I think it's the latter:
working around limitations of subRecord.  But we're hesitant to
completely rewrite the code because it's very old and very extensive.

Is there any reason to suspect that defining the macro as I have would
not work presently, or break in the future?

Thanks again.




Michael Dunning
SLAC National Accelerator Laboratory
Accelerator Research Division Test Facilities
2575 Sand Hill Road, MS 63
Menlo Park, CA 94025
+1 (650) 926-5200


On Wed, Aug 9, 2017 at 6:29 AM, Michael Davidsaver
<mdavidsaver@gmail.com> wrote:
> Are these usages about avoiding an array copy in dbGet(), or working
> around the limitations of subRecord?  In the second cause I would
> suggest to look at aSubRecord.
>
>
> dbGetPdbAddrFromLink() was removed (by me) because it exposed an
> internal implementation detail of links.  These internals change prior
> to 3.15.0.1, again in 3.16.1, and perhaps again in future.
>
> https://github.com/epics-base/epics-base/commit/74b24bbe0fd1015f13af0d70e39289efd32fd7c9
>
>
> Historically Base has exposed a lot of structures and functions which
> were not really intended/expected to be public APIs.  This makes
> maintaining or using Base all the more difficult as it isn't clear what
> was intended to be public API vs. what has become defacto public over
> the years.  Some breakage is inevitable when attempting to bring some
> order to this chaos.
>
>
>
> On 08/08/2017 10:25 PM, Stubbs, Scott A. wrote:
>> Hi, I would be interested in this as well.  We have an IOC talking to an
>> MKS RGA which also uses this macro:
>>
>>     /* Get the pointer to the record in INPB.
>>    * Is this a valid pv? If so, then verify that data type is double,
>> and check that it's a waveform.
>>    */
>>   pAddr= dbGetPdbAddrFromLink(&psub->inpc);
>>   if(!pAddr|| (pAddr->field_type != DBF_DOUBLE) || (pAddr->no_elements
>> == 1))
>>     return(ERROR);
>>
>>   /* Create an array of 2 pointers */
>>   pdev = (intArrayOut_ts *)calloc(sizeof(intArrayOut_ts),1);
>>   if(!pdev)
>>   {
>>     recGblRecordError(S_rec_outMem,(void*)psub,"sub: init_record");
>>     return(ERROR);
>>   }
>>
>>   /* Set the private data information */
>>   pwf  = (waveformRecord *)pAddr->precord;
>>   pdev->preadings = (double*)pAddr->pfield; /* ptr to data <DEVICE>:IVB */
>>   pdev->pnord = &pwf->nord;                  /* ptr to # of wf items     */
>>   pdev->nelem = pAddr->no_elements;          /* max number of data
>> elements in record   */
>>
>> Thanks,
>> Scott
>> ---
>> Scott Stubbs
>> LCLS Controls & Data Systems
>> sstubbs@slac.stanford.edu <mailto:sstubbs@slac.stanford.edu>
>>
>>
>>
>>
>>> On 4 Aug 2017, at 12:43 pm, Dunning, Michael
>>> <mdunning@slac.stanford.edu <mailto:mdunning@slac.stanford.edu>> wrote:
>>>
>>> I'm failing to come up with a clever way of replacing
>>> dbGetPdbAddrFromLink, which was removed in base 3.15.  It was defined
>>> as a macro in dbAccessDefs.h as this:
>>>
>>> #define dbGetPdbAddrFromLink(PLNK) \
>>> ( ( (PLNK)->type != DB_LINK ) \
>>> ? 0 \
>>> : ( ( (struct dbAddr *)( (PLNK)->value.pv_link.pvt) ) ) )
>>>
>>>
>>> I can redefine this macro in my source code as the above, but is there
>>> a better way of replacing its functionality, perhaps with a different
>>> macro or function call?
>>>
>>> Here's an example of how we were using it:
>>>
>>> ...
>>> DBADDR *cntAddr = dbGetPdbAddrFromLink(&psub->inpi);
>>> short *cntP;
>>> long cntNord, offset;
>>> struct rset *prset;
>>>
>>> if (!cntAddr) return -1;
>>> dbScanLock(cntAddr->precord);
>>> if ((cntAddr->field_type == DBF_SHORT) && ((prset =
>>> dbGetRset(cntAddr)))) {
>>>    cntP = (short *)cntAddr->pfield;
>>>    if (!cntP) cntNord = 0;
>>>    else (*prset->get_array_info)(cntAddr, &cntNord, &offset);
>>> } else {
>>>    cntP    = 0;
>>>    cntNord = 0;
>>> }
>>> dbScanUnlock(cntAddr->precord);
>>> ...
>>>
>>>
>>> This is for some rather critical systems, so we're trying at all costs
>>> to avoid surprise runtime errors.
>>>
>>> Any suggestions are much appreciated.
>>>
>>> Mike
>>>
>>>
>>>
>>> Michael Dunning
>>> SLAC National Accelerator Laboratory
>>> Accelerator Research Division Test Facilities
>>> 2575 Sand Hill Road, MS 63
>>> Menlo Park, CA 94025
>>> +1 (650) 926-5200
>>
>

Replies:
Re: Replacement for dbGetPdbAddrFromLink ? Andrew Johnson
References:
Replacement for dbGetPdbAddrFromLink ? Dunning, Michael
Re: Replacement for dbGetPdbAddrFromLink ? Stubbs, Scott A.
Re: Replacement for dbGetPdbAddrFromLink ? Michael Davidsaver

Navigate by Date:
Prev: Re: Archive Dump on Change Only Michael Davidsaver
Next: Re: Replacement for dbGetPdbAddrFromLink ? Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: Replacement for dbGetPdbAddrFromLink ? Michael Davidsaver
Next: Re: Replacement for dbGetPdbAddrFromLink ? Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 15 Aug 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·