89f13aa51b
Use dbLinkDoLocked() to ensure a timestamp set by TSEL=-2 comes from the same update as the value.
404 lines
16 KiB
HTML
404 lines
16 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
<title>EPICS Base R3.16.0.2 Release Notes</title>
|
|
</head>
|
|
|
|
<body lang="en">
|
|
<h1 align="center">EPICS Base Release 3.16.0.2</h1>
|
|
|
|
<p style="color:red">This version of EPICS Base has not been released yet.</p>
|
|
|
|
<h2 align="center">Changes made on the 3.16 branch since 3.15.3</h2>
|
|
<!-- Insert new items immediately below this template ...
|
|
|
|
<h3>Title...</h3>
|
|
|
|
<p>Description</p>
|
|
|
|
-->
|
|
|
|
<h3>Synchronized Timestamps with TSEL=-2</h3>
|
|
|
|
<p>Most Soft Channel input device support routines have supported fetching the
|
|
timestamp through the INP link along with the input data. However before now
|
|
there was no guarantee that the timestamp provided by a CA link came from the
|
|
same update as the data, since the two were read at separate times without
|
|
maintaining a lock on the CA input buffer. This shortcoming has been fixed as
|
|
part of the new link support code, which allows code using a link to pass a
|
|
subroutine to the link type to be run with the link locked. The subroutine may
|
|
make multiple requests for metadata from the link, but must not block.</p>
|
|
|
|
<h3>Device Support Address Type <tt>JSON_LINK</tt></h3>
|
|
|
|
<p>Device support may be written to expect hardware addresses in the new
|
|
<tt>JSON_LINK</tt> address type. Addresses loaded from a database file will be
|
|
checked against the JSON rules, and a strict JSON representation of the result
|
|
is provided as a C string pointed to by <tt>link.value.json.string</tt>.</p>
|
|
|
|
<p>Currently the device support is responsible for parsing the JSON text itself.
|
|
An event-driven JSON parser library has been included in libCom since Base-3.15,
|
|
<a href="https://lloyd.github.io/yajl/">YAJL (Yet Another JSON Library)</a>
|
|
Version 1.012, <a href="https://lloyd.github.io/yajl/yajl-1.0.12/">documented
|
|
here</a>.</p>
|
|
|
|
|
|
<h3>JSON Link Addressing</h3>
|
|
|
|
<blockquote>
|
|
|
|
<p><b style="color:red">FIXME</b> text missing here...</p>
|
|
|
|
<h4>Support routine changes</h4>
|
|
|
|
<p>For link fields in external record types and soft device support to be able
|
|
to use the new JSON link types properly, the following changes are
|
|
necessary:</p>
|
|
|
|
<ul>
|
|
|
|
<li>Make all calls to <tt>recGblInitConstantLink()</tt> unconditional on the
|
|
link type, i.e. change this code:
|
|
|
|
<pre>
|
|
if (prec->siml.type == CONSTANT) {
|
|
recGblInitConstantLink(&prec->siml, DBF_USHORT, &prec->simm);
|
|
}
|
|
</pre>
|
|
|
|
into this:
|
|
|
|
<pre>
|
|
recGblInitConstantLink(&prec->siml, DBF_USHORT, &prec->simm);
|
|
</pre>
|
|
|
|
Note that <tt>recGblInitConstantLink()</tt> still returns true if the field was
|
|
successfully initialized from the link.</li>
|
|
|
|
<li>Code like this:
|
|
|
|
<pre>
|
|
if ((prec->dol.type != CONSTANT) &&
|
|
</pre>
|
|
|
|
should usually become:
|
|
|
|
<pre>
|
|
if (!dbLinkIsConstant(&prec->dol) &&
|
|
</pre>
|
|
</li>
|
|
|
|
<li>Other code that compares a link type with CONSTANT should be modified to
|
|
use the new routine <tt>dbLinkIsConstant(plink)</tt> instead.</li>
|
|
|
|
<li>Any code that calls dbCa routines directly or that explicitly checks if a
|
|
link has been resolved as a CA link using code such as
|
|
|
|
<pre>
|
|
if (plink->type == CA_LINK)
|
|
</pre>
|
|
|
|
should be modified to use the new generic routines defined in dbLink.h. As an
|
|
example, the calcout record has been modified to use the new dbLink API.</li>
|
|
|
|
<li>...</li>
|
|
|
|
</ul>
|
|
|
|
<p><b style="color:red">FIXME</b> text missing here...</p>
|
|
|
|
</blockquote>
|
|
|
|
|
|
<h3>Constant Link Values</h3>
|
|
|
|
<p>Previously a constant link (i.e. a link that does not point to another PV,
|
|
either local or over Channel Access) has only been able to provide a numeric
|
|
value; any string found in a link field that was not recognized as a number was
|
|
treated as a PV name. In this release, constant links may contain string values,
|
|
arrays, or even arrays of strings. These are indicated by ...</p>
|
|
|
|
<p><b style="color:red">FIXME</b> text missing here...</p>
|
|
|
|
|
|
<h3>Database Parsing of "Relaxed JSON" Values</h3>
|
|
|
|
<p>A database file can now provide a "relaxed JSON" value for a database field
|
|
value or an info tag. Only a few field types can currently accept such values,
|
|
but the capability is now available for use in other places in the future. If a
|
|
JSON-capable field is written to at run-time though only strictly compliant JSON
|
|
may be used (the dbStaticLib parser rewrites relaxed JSON values into strict
|
|
JSON before passing them to the datase for interpretation, where the strict
|
|
rules must be followed).</p>
|
|
|
|
<p>"Relaxed JSON" was developed to maximize compatibility with the previous
|
|
database parser rules and reduce the number of double-quotes that would be
|
|
needed using strict JSON syntax. The parser will also accept strict JSON, which
|
|
should be used when machine-generating database files. The differences are:</p>
|
|
|
|
<ul>
|
|
|
|
<li>Strings containing only the characters <tt><b>a-z A-Z 0-9 _ - + .</b></tt>
|
|
do not have to be enclosed in double-quote characters.</li>
|
|
|
|
<li>The above rule applies to map keys as well as to regular string values.</li>
|
|
|
|
<li>The JSON keywords <tt>null</tt>, <tt>true</tt> and <tt>false</tt> (all
|
|
lower-case) will be recognized as keywords, so must be quoted to use any of
|
|
these single words as a string.</li>
|
|
|
|
<li>Comments may be used, introduced as usual by the <tt><b>#</b></tt>
|
|
character and extending to the end of the line.</li>
|
|
|
|
</ul>
|
|
|
|
<p>A JSON field or info value is only enclosed in quotes when the value being
|
|
provided is a single string, and even here the quotes can be omitted in some
|
|
cases as described above. The following shows both correct and incorrect
|
|
excerpts from a database file:</p>
|
|
|
|
<pre>
|
|
record(ai, math:pi) {
|
|
field(INP, {const: 3.14159265358979}) # Correct
|
|
field(SIOL, "{const: 3.142857}") # Wrong
|
|
|
|
info(autosave, { # White-space and comments are allowed
|
|
fields:[DESC, SIMM],
|
|
pass0:[VAL]
|
|
}) # Correct
|
|
}
|
|
</pre>
|
|
|
|
<p>Note that the record, field and info-tag names do <em>not</em> accept JSON
|
|
values, so they follows the older bareword rules for quoting where the colon
|
|
<tt><b>:</b></tt> and several additional characters are legal in a bareword
|
|
string.</p>
|
|
|
|
|
|
<h3>Echoless comments in iocsh</h3>
|
|
|
|
<p>The way comments are parsed by the iocsh interpreter has changed. The
|
|
interpreter can be selectively disabled from echoing comments coming from
|
|
a script by starting those lines with '#-' rather than just '#'.</p>
|
|
|
|
|
|
<hr>
|
|
|
|
<h2 align="center">Changes in 3.16.0.1 made since 3.15.3</h2>
|
|
|
|
<h3>Build support for CapFast and dbst removed</h3>
|
|
|
|
<p>The build rules associated with the CapFast-related tools <tt>sch2edif</tt>
|
|
and <tt>e2db</tt> and the <q>database optimization</q> tool <tt>dbst</tt> have
|
|
been removed, along with the <tt>DB_OPT</tt> build configuration variable.</p>
|
|
|
|
<h3>compressRecord buffering order</h3>
|
|
|
|
<p>The compressRecord has a new field <tt>BALG</tt> which can select between
|
|
FIFO (append) and LIFO (prepend) ordering for insertion of new elements. FIFO
|
|
ordering is the default, matching the behviour of previous versions.</p>
|
|
|
|
<h3>Valgrind Instrumentation</h3>
|
|
|
|
<p>Valgrind is a software debugging suite provided by many Linux distributions.
|
|
The header valgrind/valgrind.h is now included in, and installed by, Base.
|
|
When included by a C or C++ source file this header defines some macros which
|
|
expand to provide hints to the Valgrind runtime.
|
|
These have no effect on normal operation of the software, but when run using the
|
|
valgrind tool they can help to find memory leaks and buffer overflows.
|
|
Suitable hints have been added to several free-lists within libCom, including
|
|
freeListLib, allowing valgrind to provide more accurate information about the
|
|
source of potential leaks.</p>
|
|
|
|
<p>valgrind.h automatically disables itself when the build target is not
|
|
supported by the valgrind tool.
|
|
It can also explicitly be disabled by defining the macro <em>NVALGRIND</em>.
|
|
See <em>src/libCom/Makefile</em> for a commented-out example.</p>
|
|
|
|
<p>As a matter of policy valgrind.h will never be included by any header file
|
|
installed by Base, so its use will remain purely an implementation
|
|
detail hidden from application software.
|
|
Support modules which choose to use valgrind.h are advised to do
|
|
likewise.</p>
|
|
|
|
<h3>Database Multi-locking</h3>
|
|
|
|
<p>The IOC record locking code has been re-written with an expanded API; global
|
|
locks are no longer required by the IOC database implementation.</p>
|
|
|
|
<p>The new API functions center around dbScanLockMany(), which behaves like
|
|
dbScanLock() applied to an arbitrary group of records. dbLockerAlloc() is used
|
|
to prepare a list or record pointers, then dbScanLockMany() is called. When it
|
|
returns, all of the records listed may be accessed (in any order) until
|
|
dbScanUnlockMany() is called.</p>
|
|
|
|
<p>The Application Developer's Guide has been updated to describe the API and
|
|
implementation is more detail.</p>
|
|
|
|
<p>Previously a global mutex 'lockSetModifyLock' was locked and unlocked during
|
|
dbScanLock(), acting as a sequencing point for otherwise unrelated calls. The
|
|
new dbLock.c implementation does not include any global mutex in dbScanLock() or
|
|
dbScanLockMany(). Locking/unlocking of unrelated lock sets is now completely
|
|
concurrent.</p>
|
|
|
|
<h3>Generate Version Header</h3>
|
|
|
|
<p>A Perl script and Makefile rules have been added to allow modules to generate
|
|
a C header file with a macro defined with an automatically updated identifier.
|
|
This is a VCS revision ID (Darcs, Git, Mercurial, Subversion, and Bazaar are
|
|
supported) or the date/time of the build if no VCS system is in use.</p>
|
|
|
|
<p>The makeBaseApp example template has been updated with a new device support
|
|
which makes this identifier visible via a lsi (long string input) record.</p>
|
|
|
|
<h3>epicsTime API return status</h3>
|
|
|
|
<p>The epicsTime routines that used to return epicsTimeERROR now return a
|
|
specific S_time_ status value, allowing the caller to discover the reason for
|
|
any failure. The identifier <tt>epicsTimeERROR</tt> is no longer defined, so any
|
|
references to it in source code will no longer compile. The identifier
|
|
epicsTimeOK still exists and has the value 0 as before, so most code that uses
|
|
these APIs can be changed in a way that is backwards-compatible with the
|
|
previous return status.</p>
|
|
|
|
<p>Time providers that have to return a status value and still need to be built
|
|
with earlier versions of Base can define the necessary status symbols like
|
|
this:</p>
|
|
|
|
<blockquote><pre>
|
|
#include "epicsTime.h"
|
|
|
|
#ifndef M_time
|
|
/* S_time_... status values were not provided before Base 3.16 */
|
|
#define S_time_unsynchronized epicsTimeERROR
|
|
#define S_time_...whatever... epicsTimeERROR
|
|
#endif
|
|
</pre></blockquote>
|
|
|
|
<h3>Refactoring of epicsReadline</h3>
|
|
|
|
<p>The epicsReadline code has been reorganized to allow the commandline history
|
|
editor to be disabled at runtime. The EPICS_COMMANDLINE_LIBRARY build setting
|
|
still selects the preferred editor, but the new <tt>IOCSH_HISTEDIT_DISABLE</tt>
|
|
environment variable can be set at runtime to disable history editing and make
|
|
the IOC or other program use the basic editor instead. This is useful when
|
|
starting and controlling an IOC from another program through its stdin and
|
|
stdout streams since history editors often insert invisible escape codes into
|
|
the stdout stream, making it hard to parse.</p>
|
|
|
|
<h3>Callback subsystem API</h3>
|
|
|
|
<p>Added a new macro <tt>callbackGetPriority(prio, callback)</tt> to the
|
|
callback.h header and removed the need for dbScan.c to reach into the internals
|
|
of its CALLBACK objects.</p>
|
|
|
|
|
|
<h2 align="center">Changes pulled from the 3.15 branch since 3.15.3</h2>
|
|
|
|
<h3>CA server configuration changes</h3>
|
|
|
|
<p>RSRV now honors EPICS_CAS_INTF_ADDR_LIST and binds only to the provided list
|
|
of network interfaces. Name searches (UDP and TCP) on other network interfaces
|
|
are ignored. For example on a computer with interfaces 10.5.1.1/24, 10.5.2.1/24,
|
|
and 10.5.3.1/24, setting "EPICS_CAS_INTF_ADDR_LIST='10.5.1.1 10.5.2.1'" will
|
|
accept traffic on the .1.1 and .2.1, but ignore from .3.1</p>
|
|
|
|
<p>RSRV now honors EPICS_CAS_IGNORE_ADDR_LIST and ignores UDP messages received
|
|
from addresses in this list.</p>
|
|
|
|
<p>Previously, CA servers (RSRV and PCAS) would build the beacon address list
|
|
using EPICS_CA_ADDR_LIST if EPICS_CAS_BEACON_ADDR_LIST was no set. This is no
|
|
longer done. Sites depending on this should set both envronment variables to the
|
|
same value.</p>
|
|
|
|
<h3>IPv4 multicast for name search and beacons</h3>
|
|
|
|
<p>libca, RSRV, and PCAS may now use IPv4 multicasting for UDP traffic (name
|
|
search and beacons). This is disabled by default. To enable multicast address(s)
|
|
must be listed in EPICS_CA_ADDR_LIST for clients and EPICS_CAS_INTF_ADDR_LIST
|
|
for servers (IOCs should set both). For example:
|
|
"EPICS_CAS_INTF_ADDR_LIST='224.0.2.9' EPICS_CA_ADDR_LIST=224.0.2.9".</p>
|
|
|
|
<p>Please note that no IPv4 multicast address is officially assigned for Channel
|
|
Access by IANA. The example 224.0.2.9 is taken from the AD-HOC Block I range.<p>
|
|
|
|
<h3>Moved <tt>mlockall()</tt> into its own epicsThread routine</h3>
|
|
|
|
<p>Since EPICS Base 3.15.0.2 on Posix OSs the initialization of the epicsThread
|
|
subsystem has called <tt>mlockall()</tt> when the OS supports it and thread
|
|
priority scheduling is enabled. Doing so has caused problems in third-party
|
|
applications that call the CA client library, so the functionality has been
|
|
moved to a separate routine <tt>epicsThreadRealtimeLock()</tt> which will be
|
|
called by the IOC at iocInit (unless disabled by setting the global variable
|
|
<tt>dbThreadRealtimeLock</tt> to zero).</p>
|
|
|
|
<h3>Added dbQuietMacroWarnings control</h3>
|
|
|
|
<p>When loading database files, macros get expanded even on comment lines. If a
|
|
comment contains an undefined macro, the load still continues but an error
|
|
message gets printed. For this release the error message has been changed to a
|
|
warning, but even this warning can be made less verbose by setting this new
|
|
variable to a non-zero value before loading the file, like this:</p>
|
|
|
|
<blockquote><pre>
|
|
var dbQuietMacroWarnings 1 <i>iocsh</i>
|
|
dbQuietMacroWarnings=1 <i>VxWorks</i>
|
|
</pre></blockquote>
|
|
|
|
<p>This was <a href="https://bugs.launchpad.net/bugs/541119">Launchpad bug
|
|
541119</a>.</p>
|
|
|
|
|
|
<h2 align="center">Changes pulled from the 3.14 branch since 3.15.3</h2>
|
|
|
|
<h3>String field buffer overflows</h3>
|
|
|
|
<p>Two buffer overflow bugs that can crash the IOC have been fixed, caused by
|
|
initializing a string field with a value larger than the field size
|
|
(<a href="https://bugs.launchpad.net/bugs/1563191">Launchpad bug
|
|
#1563191</a>).</p>
|
|
|
|
<h3>Fixed stack corruption bug in epicsThread C++ API</h3>
|
|
|
|
<p>The C++ interface to the epicsThread API could corrupt the stack on thread
|
|
exit in some rare circumstances, usually at program exit. This bug has been
|
|
fixed (<a href="https://bugs.launchpad.net/bugs/1558206">Launchpad bug
|
|
#1558206</a>).</p>
|
|
|
|
<h3>RTEMS NTP Support Issue</h3>
|
|
|
|
<p>On RTEMS the NTP Time Provider could in some circumstances get out of sync
|
|
with the server because the osdNTPGet() code wasn't clearing its input socket
|
|
before sending out a new request. This
|
|
(<a href="https://bugs.launchpad.net/bugs/1549908">Launchpad bug 1549908</a>)
|
|
has now been fixed.</p>
|
|
|
|
<h3>CALC engine bitwise operator fixes</h3>
|
|
|
|
<p>The bitwise operators in the CALC engine have been modified to work properly
|
|
with values that have bit 31 (0x80000000) set. This modification involved
|
|
back-porting some earlier changes from the 3.15 branch, and fixes
|
|
<a href="https://code.launchpad.net/bugs/1514520">Launchpad bug
|
|
#1514520</a>.</p>
|
|
|
|
<h3>Fix <tt>ipAddrToAsciiAsync()</tt>: Don't try to join the daemon thread</h3>
|
|
|
|
<p>On process exit, don't try to stop the worker thread that makes DNS lookups
|
|
asynchronous. Previously this would wait for any lookups still in progress,
|
|
delaying the exit unnecessarily. This was most obvious with catools (eg.
|
|
cainfo).
|
|
<a href="https://bugs.launchpad.net/bugs/1527636">lp:1527636</a></p>
|
|
|
|
<h3>Fix <tt>epicsTime_localtime()</tt> on Windows</h3>
|
|
|
|
<p>Simpler versions of the epicsTime_gmtime() and epicsTime_localtime()
|
|
routines have been included in the Windows implementations, and a new test
|
|
program added. The original versions do not report DST status properly. Fixes
|
|
<a href="https://bugs.launchpad.net/bugs/1528284">Launchpad bug 1528284</a>.</p>
|
|
|
|
|
|
</body>
|
|
</html>
|