epics/epics-base
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity
Files
fe1ec6ed3132c40d4a4e2dbe7bcfff0ca234572c
epics-base/documentation/RELEASE_NOTES.html
Andrew Johnson fe1ec6ed31 Replace > with > in Release Notes code examples
2018-05-28 17:40:57 -05:00

1171 lines
51 KiB
HTML
Raw Blame History

<!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.2 Release Notes</title>
</head>
<body lang="en">
<h1 align="center">EPICS Base Release 3.16.2</h1>
<h2 align="center">Changes made between 3.16.1 and 3.16.2</h2>
<!-- Insert new items immediately below this template ...
<h3>Title...</h3>
<p>Description</p>
-->
<h3>Record types mbbiDirect and mbboDirect extended to 32 bit</h3>
<p>The VAL fields of mbbiDirect and mbboDirect records have
been extended from <tt>DBF_USHORT</tt> (16 bit) to <tt>DBF_LONG</tt> (32 bit).
New bit fields <tt>B10</tt>...<tt>B1F</tt> have been added.</p>
<p>Device support which accesses the bit fields can test if the macro
<tt>mbbiDirectRecord1BF</tt> or <tt>mbboDirectRecord1BF</tt> is
defined. Device support which only accesses RVAL needs no modification.</p>
<h3>Restore use of ledlib for VxWorks command editing</h3>
<p>The epicsReadline refactoring work described below unfortunately disabled the
VxWorks implementation of the osdReadline.c API that uses ledlib for command
editing and history. This functionality has now been restored, see Launchpad
<a href="https://bugs.launchpad.net/bugs/1741578">bug #1741578</a>.</p>
<h3>Constant link types</h3>
<p>Constant links can now hold 64-bit integer values, either as scalars or
arrays. Only base 10 is supported by the JSON parser though, the JSON standard
doesn't allow for hexadecimal numbers.</p>
<h3>Upgraded the YAJL JSON Library</h3>
<p>The third-party YAJL library that has been included in libCom for several
years has been upgraded to version 2.1.0 and several bugs fixed. This has an
updated API, requiring any code that uses it to parse its own JSON files to be
modified to match. The changes are mainly that it uses <tt>size_t</tt> instead
<tt>unsigned int</tt> for string lengths, but it also uses <tt>long long</tt>
instead of <tt>long</tt> for JSON integer values, which was the main motivation
for the upgrade.</p>
<p>The self-tests that YAJL comes with have been imported and are now run as an
EPICS Unit Test program, and the JSON syntax accepted by the parser was extended
to permit trailing commas in both arrays and maps. The difference between the
old and new YAJL APIs can be detected at compile time by looking for the macro
<tt>EPICS_YAJL_VERSION</tt> which is defined in the yajl_common.h header file
along with a brief description of the API changes.</p>
<h3>Timestamp support for the calc link type</h3>
<p>A new optional parameter can be given when specifying a calc JSON link. The
<tt>time</tt> parameter is a string containing a single letter <tt>A..L</tt>
that selects one of the input links to be used for the timestamp of calculation
if requested. The timestamp will be fetched atomically with the value from the
chosen input link (providing that input link type supports the readLocked()
method).</p>
<h3>Silence errors from puts to constant link types</h3>
<p>A soft channel output record with the OUT link unset uses the CONSTANT link
type. The new link type code was causing some soft channel device supports to
return an error status from the write method of that link type, which would
cause a ca_put() operation to such a record to generate an exception. This has
been silenced by giving the constant link types a dummy putValue method. A new
test program has been added to prevent regressions of this behaviour.</p>
<h3>RSRV expanding large buffer causes crash</h3>
<p>In the 3.16.1 release a crash can occur in the IOC's RSRV server when a large
array is made even larger; the previous array buffer was not being released
correctly. See Launchpad
<a href="https://bugs.launchpad.net/epics-base/+bug/1706703">bug
#1706703</a>.</p>
<h2 align="center">Changes made between 3.16.0.1 and 3.16.1</h2>
<h3>IOC Database Support for 64-bit integers</h3>
<p>The IOC now supports the 64-bit integer field types <tt>DBF_INT64</tt> and
<tt>DBF_UINT64</tt>, and there are new record types <tt>int64in</tt> and
<tt>int64out</tt> derived from the <tt>longin</tt> and <tt>longout</tt> types
respectively that use the <tt>DBF_INT64</tt> data type for their VAL and related
fields. The usual range of Soft Channel device support are included for these
new record types.</p>
<p>All internal IOC APIs such as dbAccess can handle the new field types and
their associated request values <tt>DBR_INT64</tt> and <tt>DBR_UINT64</tt>,
which are implemented using the <tt>epicsInt64</tt> and <tt>epicsUInt64</tt>
typedef's from the <tt>epicsTypes.h</tt> header.</p>
<p>The waveform record type has been updated to support these new field types.
<strong>All waveform device support layers must be updated to recognize the new
type enumeration values</strong>, which had to be inserted before the
<tt>FLOAT</tt> value in the enum <tt>dbfType</tt> and in <tt>menuFtype</tt>. C
or C++ code can detect at compile-time whether this version of base provides
64-bit support by checking for the presence of the <tt>DBR_INT64</tt> macro as
follows (Note that <tt>DB<b>F</b>_INT64</tt> is an enum tag and not a
preprocessor macro):</p>
<blockquote><pre>
#ifdef DBR_INT64
/* Code where Base has INT64 support */
#else
/* Code for older versions */
#endif
</pre></blockquote>
<p>If the code uses the old db_access.h types (probably because it's calling
Channel Access APIs) then it will have to test against the EPICS version number
instead, like this:</p>
<blockquote><pre>
#include &lt;epicsVersion.h&gt;
#ifndef VERSION_INT
# define VERSION_INT(V,R,M,P) ( ((V)&lt;&lt;24) | ((R)&lt;&lt;16) | ((M)&lt;&lt;8) | (P))
#endif
#ifndef EPICS_VERSION_INT
# define EPICS_VERSION_INT VERSION_INT(EPICS_VERSION, EPICS_REVISION, EPICS_MODIFICATION, EPICS_PATCH_LEVEL)
#endif
#if EPICS_VERSION_INT &gt;= VERSION_INT(3,16,1,0)
/* Code where Base has INT64 support */
#else
/* Code for older versions */
#endif
</pre></blockquote>
<p>Channel Access does not (and probably never will) directly support 64-bit
integer types, so the new field types are presented to the CA server as
<tt>DBF_DOUBLE</tt> values. This means that field values larger than 2^52
(0x10_0000_0000_0000 = 4503599627370496) cannot be transported over Channel
Access without their least significant bits being truncated. The EPICS V4
pvAccess network protocol <em>can</em> transport 64-bit data types however, and
a future release of the pvaSrv module will connect this ability to the fields of
the IOC.</p>
<p>Additional 64-bit support will be provided in later release. For instance the
JSON parser for the new Link Support feature only handles integers up to
32&nbsp;bits wide, so constant array initializer values cannot hold larger
values in this release.</p>
<h3>Add EPICS_CA_MCAST_TTL</h3>
<p>A new environment parameter EPICS_CA_MCAST_TTL is used to set the Time To
Live (TTL) value of any IP multi-cast CA search or beacon packets sent.</p>
<h3>EPICS_CA_MAX_ARRAY_BYTES is optional</h3>
<p>A new environment parameter EPICS_CA_AUTO_ARRAY_BYTES is now used by libca
and RSRV (CA clients and the IOC CA server). The default is equivalent to
setting EPICS_CA_AUTO_ARRAY_BYTES=YES which removes the need to set
EPICS_CA_MAX_ARRAY_BYTES and always attempts to allocate sufficiently large
network buffers to transfer large arrays properly over the network. In this case
the value of the EPICS_CA_MAX_ARRAY_BYTES parameter is ignored.</p>
<p>Explicitly setting EPICS_CA_AUTO_ARRAY_BYTES=NO will continue to honor the
buffer setting in EPICS_CA_AUTO_ARRAY_BYTES as in previous releases.</p>
<p>The default setting for EPICS_CA_AUTO_ARRAY_BYTES can be changed by
adding the line</p>
<blockquote><pre>
EPICS_CA_AUTO_ARRAY_BYTES=NO
</pre></blockquote>
<p>to the configure/CONFIG_SITE_ENV file before building Base. Sites that wish
to override this only for specific IOC architectures can create new files for
each architecture named configure/os/CONFIG_SITE_ENV.&lt;target-arch&gt; with
the above setting in before building Base. The configuration can also be
explicitly changed by setting the environment variable in the IOC's startup
script, anywhere above the <tt>iocInit</tt> line.</p>
<p>The PCAS server (used by the PV Gateway and other CA servers) now always
behaves as if EPICS_CA_AUTO_ARRAY_BYTES is set to YES (it ignores the
configuration parameter and environment variable).</p>
<h3>Channel Access "modernization"</h3>
<p>Drop support for CA clients advertising protocol versions less than 4.</p>
<p>This effects clients from Base older than 3.12.0-beta1.
Newer clients will continue to be able to connect to older servers.
Older clients will be ignored by newer servers.</p>
<p>This allows removal of UDP echo and similar protocol features which
are not compatible with secure protocol design practice.</p>
<h3>Lookup-tables using the subArrray record</h3>
<p>The subArray record can now be used as a lookup-table from a constant array
specified in its INP field. For example:</p>
<pre>
record(subArray, "powers-of-2") {
field(FTVL, "LONG")
field(MALM, 12)
field(INP, [1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048])
field(INDX, 0)
field(NELM, 1)
}
</pre>
<p>The INDX field selects which power of 2 to set the VAL field to. In previous
releases the INP field would have to have been pointed to a separate waveform
record that was initialized with the array values somehow at initialization
time.</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 from the CA input buffer at
separate times without maintaining a lock on that buffer in between. This
shortcoming could be fixed as a result of the new link support code, which
allows code using a link to pass a subroutine to the link type which will be run
with the link locked. The subroutine may make multiple requests for metadata
from the link, but must not block.</p>
<h3>Extensible Link Types</h3>
<blockquote>
<p>A major new feature introduced with this release of EPICS Base is an
Extensible Link Type mechanism, also known as Link Support or JSON Link Types.
This addition permits new kinds of link I/O to be added to an IOC in a similar
manner to the other extension points already supported (e.g. record, device and
driver support).</p>
<p>A new link type must implement two related APIs, one for parsing the JSON
string which provides the link address and the other which implements the link
operations that get called at run-time to perform I/O. The link type is built
into the IOC by providing a new <tt>link</tt> entry in a DBD file.</p>
<h4>New Link Types Added</h4>
<p>This release contains two new JSON link types, <tt>const</tt> and
<tt>calc</tt>:</p>
<ul>
<li>The <tt>const</tt> link type is almost equivalent to the old CONSTANT link
type with the updates described below to accept arrays and strings, except that
there is no need to wrap a scalar string constant inside array brackets since a
constant string will never be confused with a PV name.</li>
<li>The <tt>calc</tt> link type allows CALC expressions to be used to combine
values from other JSON links to produce its value. Until additional JSON link
types are created though, the <tt>calc</tt> link type has little practical
utility as it can currently only fetch inputs from other <tt>calc</tt> links or
from <tt>const</tt> links.</li>
</ul>
<pre>
field(INP, {calc:{expr:"A+B+1",
args:[5, # A
{const:6}] # B
}})
</pre>
<p>The new link types are documented in a
<a href="links.html">separate</a><!-- href for the EPICS website -->
<a href="../html/links.html">document</a><!-- href for install tree -->
.</p>
<h4>Device Support Addressing using <tt>JSON_LINK</tt></h3>
<p>The API to allow device support to use JSON addresses is currently
incomplete; developers are advised not to try creating device support that
specifies a <tt>JSON_LINK</tt> address type.</p>
<h4>Support Routine Modifications for Extensible Link Types</h4>
<p>For link fields in external record types and soft device support to be able
to use the new link types properly, various changes are required to utilize the
new Link Support API as defined in the dbLink.h header file and outlined below.
The existing built-in Database and Channel Access link types have been altered
to implement the link APIs, so will work properly after these conversions:</p>
<ul>
<li>Make all calls to <tt>recGblInitConstantLink()</tt> unconditional on the
link type, i.e. change this code:
<pre>
if (prec-&gt;siml.type == CONSTANT) {
recGblInitConstantLink(&amp;prec-&gt;siml, DBF_USHORT, &amp;prec-&gt;simm);
}
</pre>
into this:
<pre>
recGblInitConstantLink(&amp;prec-&gt;siml, DBF_USHORT, &amp;prec-&gt;simm);
</pre>
Note that <tt>recGblInitConstantLink()</tt> still returns TRUE if the field was
successfully initialized from the link (implying the link is constant).<br />
This change will work properly with all Base releases currently in use.</li>
<li>Code that needs to identify a constant link should be modified to use the
new routine <tt>dbLinkIsConstant()</tt> instead, which returns TRUE for constant
or undefined links, FALSE for links whose <tt>dbGetLink()</tt> routine may
return different values on different calls. For example this:
<pre>
if (prec-&gt;dol.type != CONSTANT)
</pre>
should become this:
<pre>
if (!dbLinkIsConstant(&amp;prec-&gt;dol))
</pre>
When the converted software is also required to build against older versions of
Base, this macro definition may be useful:
<pre>
#define dbLinkIsConstant(lnk) ((lnk)-&gt;type == CONSTANT)
</pre>
</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 (prec-&gt;inp.type == CA_LINK)
</pre>
will still compile and run, but will only work properly with the old CA link
type. To operate with the new extensible link types such code must be modified
to use the new generic routines defined in dbLink.h and should never attempt to
examine or modify data inside the link. After conversion the above line would
probably become:
<pre>
if (dbLinkIsVolatile(&amp;prec-&gt;inp))
</pre>
A volatile link is one like a Channel Access link which may disconnect and
reconnect without notice at runtime. Database links and constant links are not
volatile; unless their link address is changed they will always remain in the
same state they started in. For compatibility when building against older
versions of Base, this macro definition may be useful:
<pre>
#define dbLinkIsVolatile(lnk) ((lnk)-&gt;type == CA_LINK)
</pre>
</li>
<li>The current connection state of a volatile link can be found using the
routine <tt>dbIsLinkConnected()</tt> which will only return TRUE for a volatile
link that is currently connected. Code using the older dbCa API returning this
information used to look like this:
<pre>
stat = dbCaIsLinkConnected(plink);
</pre>
which should become:
<pre>
stat = dbIsLinkConnected(plink);
</pre>
Similar changes should be made for calls to the other dbCa routines.</li>
<li>A full example can be found by looking at the changes to the calcout record
type, which has been modified in this release to use the new dbLink generic
API.</li>
</ul>
</blockquote>
<h3>Constant Link Values</h3>
<p>Previously a constant link (i.e. a link that did not point to another PV,
either locally or over Channel Access) was only able to provide a single numeric
value to a record initialization; any string given in a link field that was not
recognized as a number was treated as a PV name. In this release, constant links
can be expressed using JSON array syntax and may provide array initialization of
values containing integers, doubles or strings. An array containing a single
string value can also be used to initialize scalar strings, so the stringin,
stringout, lsi (long string input), lso (long string output), printf, waveform,
subArray and aai (analog array input) record types and/or their soft device
supports have been modified to support this.</p>
<p>Some examples of constant array and string initialized records are:</p>
<pre>
record(stringin, "const:string") {
field(INP, ["Not-a-PV-name"])
}
record(waveform, "const:longs") {
field(FTVL, LONG)
field(NELM, 10)
field(INP, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10])
}
record(aai, "const:doubles") {
field(FTVL, DOUBLE)
field(NELM, 10)
field(INP, [0, 1, 1.6e-19, 2.718, 3.141593])
}
record(aSub, "select") {
field(FTA, STRING)
field(NOA, 4)
field(INPA, ["Zero", "One", "Two", "Three"])
field(FTB, SHORT)
field(NOB, 1)
field(FTVA, STRING)
field(NOVA, 1)
field(SNAM, "select_asub")
}
</pre>
<p>Reminder: Link initialization with constant values normally only occurs at
record initialization time. The calcout and printf record types are the only
exceptions in the Base record types to this rule, so it is generally not useful
to change a const link value after iocInit.</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. When
writing to a JSON-capable field at run-time however, 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 for strict JSON syntax. The parser does accept strict JSON too though,
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 they 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. Only the value (after the comma) is parsed as JSON. The autosave module
has not been modified to accept JSON syntax, the above is only an example of
how JSON might be used.</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>
<h3>Typed record support methods</h3>
<p>The table of record support functions (rset methods for short) no longer
has entries of type <tt>RECSUPFUN</tt> (which says: any number and type of
arguments). Instead, rset methods are now typed by default. The
<tt>RECSUPFUN</tt> typedef has been deprecated and casts to it as well as
using the untyped <tt>struct rset</tt> will create compilation warnings.</p>
<p>Existing code (e.g. external record supports) will generate such
warnings when compiled against this version of Base, but it will work
without changes.</p>
<p>For a conversion period, the new typed rset definitions are activated
by defining <tt>USE_TYPED_RSET</tt>, preferably by setting
<tt>USR_CPPFLAGS += -DUSE_TYPED_RSET</tt> inside a Makefile.
After activating the new typed rset in this way and making the following
changes, the result should still compile and work properly against older
versions of Base.</p>
<p>The first parameter of <tt>init_record</tt> and <tt>process</tt> has been
changed to <tt>struct dbCommon *</tt>. Record types that use
<tt>void*</tt> here should be changed to use <tt>struct dbCommon*</tt>, and
cast the argument to their own <tt>xxxRecord *</tt>.</p>
<p>When compiled against this release, compiler warnings about incompatible
types for the method pointers should be taken seriously. When compiled
against older versions of base, such warnings are unavoidable.</p>
<p>Record types written in C++ need to take more drastic measures because of
the stricter type checking in C++. To remain compatible with older versions
of base you will need to use something like:</p>
<blockquote><pre>
#include "epicsVersion.h"
#ifdef VERSION_INT
# if EPICS_VERSION_INT < VERSION_INT(3,16,0,2)
# define RECSUPFUN_CAST (RECSUPFUN)
# else
# define RECSUPFUN_CAST
# endif
#else
# define RECSUPFUN_CAST (RECSUPFUN)
#endif
</pre></blockquote>
<p>and then replace <tt>(RECSUPFUN)</tt> with <tt>RECSUPFUN_CAST</tt>
when initializing the rset.
Further changes might also be needed, e.g. to adapt <tt>const</tt>-ness of
method parameters.</p>
<hr>
<h2 align="center">Changes made between 3.15.3 and 3.16.0.1</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 from the 3.15 branch since 3.15.5</h2>
<!-- Insert inherited items immediately below here ... -->
<h3>Fix problem with numeric soft events</h3>
<p>Changing from numeric to named soft events introduced an incompatibility
when a numeric event 1-255 is converted from a DOUBLE, e.g. from a calc record.
The <tt>post_event()</tt> API is not marked deprecated any more.
<p>Also <code>scanpel</code> has been modified to accept a glob pattern for
event name filtering and to show events with no connected records as well.</p>
<h3>Add osiSockOptMcastLoop_t and osiSockTest</h3>
<p>Added a new OS-independent typedef for multicast socket options, and a test
file to check their correct operation.<p>
<h3>Support for CONFIG_SITE.local in Base</h3>
<p>This feature is mostly meant for use by developers; configuration
settings that would normally appear in Base/configure/CONFIG_SITE can now
be put in a locally created base/configure/CONFIG_SITE.local file instead
of having go modify or replace the original. A new .gitignore pattern
tells git to ignore all configure/*.local files.</p>
<h2 align="center">Changes from the 3.14 branch since 3.15.5</h2>
<!-- Insert inherited items immediately below here ... -->
<h3>Fixes for Launchpad bugs</h3>
<p>The following launchpad bugs have fixes included:</p>
<ul>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1747091">
lp: #1747091</a>, epicsTimeGetEvent() / generalTime bug</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1743076">
lp: #1743076</a>, Segfault in ca_attach_context() during exits</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1751380">
lp: #1751380</a>, Deadlock in ca_clear_subscription()</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1597809">
lp: #1597809</a>, Setting NAME field in DB file may break IOC</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1770292">
lp: #1770292</a>, get_alarm_double() inconsistent across record types</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1771298">
lp: #1771298</a>, Conversion of NaN to integer relies on undefined
behavior</li>
</ul>
<h3>Updated VxWorks Timezone settings</h3>
<p>Removed the settings for 2017; fixed the hour of the change for MET.</p>
<h3>Fixed camonitor server side relative timestamps bug</h3>
<p>Initialize the first time-stamp from the first monitor, not the client-side
current time in this configuration.</p>
<h3>Build changes for MSVC</h3>
<p>Windows builds using Visual Studio 2015 and later now use the <tt>-FS</tt>
compiler option to allow parallel builds to work properly.</p>
<p>We now give the <tt>-FC</tt> option to tell the compiler to print absolute
paths for source files in diagnostic messages.</p>
<h3>Extend maximum Posix epicsEventWaitWithTimeout() delay</h3>
<p>The Posix implementation of epicsEventWaitWithTimeout() was limiting the
timeout delay to at most 60 minutes (3600.0 seconds). This has been changed to
10 years; significantly longer maximum delays cause problems on systems where
<tt>time_t</tt> is still a signed 32-bit integer so cannot represent absolute
time-stamps after 2038-01-19. Our assumption is that such 32-bit systems will
have been retired before the year 2028, but some additional tests have been
added to the epicsTimeTest program to detect and fail if this assumption is
violated.</p>
<h3>New test-related make targets</h3>
<p>This release adds several new make targets intended for use by developers
and Continuous Integration systems which simplify the task of running the
built-in self-test programs and viewing the results. Since these targets are
intended for limited use they can have requirements for the build host which
go beyond the standard minimum set needed to build and run Base.</p>
<blockquote>
<h4><tt>test-results</tt> &mdash; Summarize test results</h4>
<p>The new make target <tt>test-results</tt> will run the self-tests if
necessary to generate a TAP file for each test, then summarizes the TAP output
files in each test directory in turn, displaying the details of any failures.
This step uses the program <q>prove</q> which comes with Perl, but also needs
<q>cat</q> to be provided in the default search path so will not work on most
Windows systems.</p>
<h4><tt>junitfiles</tt> &mdash; Convert test results to JUnit XML Format</h4>
<p>The new make target <tt>junitfiles</tt> will run the self-tests if necessary
and then convert the TAP output files into the more commonly-supported JUnit
XML format. The program that performs this conversion needs the Perl module
<q><tt>XML::Generator</tt></q> to have been installed.</p>
<h4><tt>clean-tests</tt> &mdash; Delete test result files</h4>
<p>The new make target <tt>clean-tests</tt> removes any test result files from
previous test runs. It cleans both TAP and JUnit XML files.</p>
</blockquote>
<h3>Fix DNS related crash on exit</h3>
<p>The attempt to fix DNS related delays for short lived CLI programs (eg. caget)
in lp:1527636 introduced a bug which cased these short lived clients to crash on exit.
This bug should now be fixed.</p>
<h3>Server bind issue on Windows</h3>
<p>When a National Instruments network variables CA server is already running on
a Windows system and an IOC or PCAS server is started, the IOC's attempt to
bind a TCP socket to the CA server port number fails, but Windows returns a
different error status value than the IOC is expecting in that circumstance
(because the National Instruments code requests exclusive use of that port,
unlike the EPICS code) so the IOC fails to start properly. The relevent EPICS
bind() checks have now been updated so the IOC will request that a dynamic port
number be allocated for this TCP socket instead when this happens.</p>
<h3>Checking Periodic Scan Rates</h3>
<p>Code has been added to the IOC startup to better protect it against bad
periodic scan rates, including against locales where <q><tt>.</tt></q> is not
accepted as a decimal separator character. If the scan period in a menuScan
choice string cannot be parsed, the associated periodic scan thread will no
longer be started by the IOC and a warning message will be displayed at iocInit
time. The <tt>scanppl</tt> command will also flag the faulty menuScan value.</p>
<h2 align="center">Changes made between 3.15.4 and 3.15.5</h2>
<h3>dbStatic Library Speedup and Cleanup</h3>
<p>Loading of database files has been optimized to avoid overproportionally
long loading times for large databases. As a part of this, the alphabetical
ordering of records instances (within a record type) has been dropped. In the
unexpected case that applications were relying on the alphabetic order, setting
<tt>dbRecordsAbcSorted = 1</tt> before loading the databases will retain the
old behavior.</p>
<p>The routine <tt>dbRenameRecord()</tt> has been removed, as it was intended
to be used by database configuration tools linked against a host side version
of the dbStatic library that is not being built anymore.</p>
<h3>Launchpad Bug-fixes</h3>
<p>In addition to the more detailed change descriptions below, the following
Launchpad bugs have also been fixed in this release:</p>
<ul>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1440186">
#1440186</a> Crash due to a too small buffer being provided in
dbContextReadNotifyCache</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1479316">
#1479316</a> Some data races found using Helgrind</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1495833">
#1495833</a> biRecord prompt groups are nonsensical</li>
<li><a href="https://bugs.launchpad.net/epics-base/+bug/1606848">
#1606848</a> WSAIoctl SIO_GET_INTERFACE_LIST failed in Windows</li>
</ul>
<h3>Whole-Program Optimization for MS Visual Studio Targets</h3>
<p>When using the Microsoft compilers a new build system variable is provided
that controls whether whole program optimization is used or not. For static
builds using Visual Studio 2010 this optimization must be disabled. This is
controlled in the files configure/os/CONFIG_SITE.Common.windows-x64-static and
configure/os/CONFIG_SITE.Common.win32-x86-static by setting the variable
<tt>OPT_WHOLE_PROGRAM&nbsp;=&nbsp;NO</tt> to override the default value
<tt>YES</tt> that would otherwise be used.</p>
<p>Note that enabling this optimization slows down the build process. It is not
possible to selectively disable this optimization, when building a particular
module say; Microsoft's linker will restart itself automatically with the
<tt>-LTCG</tt> flag set and display a warning if it is asked to link any object
files that were compiled with the <tt>-GL</tt> flag.</p>
<h3>Add dynamic (variable length) array support to PCAS</h3>
<p>Dynamic array sizing support was added to the IOC server (RSRV) in the
Base-3.14.12 release, but has not until now been supported in the <q>Portable
Channel Access Server</q> (PCAS). Channel Access server applications using the
PCAS may not need to be modified at all; if they already push monitors with
different gdd array lengths, those variable sizes will be forwarded to any CA
clients who have requested variable length updates. The example CAS server
application has been modified to demonstrate this feature.</p>
<p>In implementing the above, the gdd method <tt>gdd::put(const gdd *)</tt> now
copies the full-sized array from the source gdd if the destination gdd is of
type array, has no allocated memory and a boundary size of 0.</p>
<h3>Additional epicsTime conversion</h3>
<p>The EPICS timestamp library (epicsTime) inside libCom's OSI layer has
been extended by routines that convert from <tt>struct tm</tt> to the EPICS
internal <tt>epicsTime</tt> type, assuming UTC - i.e. without going through
the timezone mechanism. This solves issues with converting from the structured
type to the EPICS timestamp at driver level from multiple threads at a high
repetition rate, where the timezone mechanism was blocking on file access.</p>
<h3>MinGW Cross-builds from Linux</h3>
<p>The build configuration files that allow cross-building of the 32-bit
win32-x86-mingw cross-target have been adjusted to default to building shared
libraries (DLLs) as this is now supported by recent MinGW compilers. The 64-bit
windows-x64-mingw cross-target was already being built that way by default. The
configuration options to tell the minGW cross-compiler to link programs with
static versions of the compiler support libraries have now been moved into the
CONFIG_SITE.linux-x86.<i>target</i> files.</p>
<h3>General Time updates</h3>
<p>The <tt>iocInit</tt> code now performs a sanity check of the current time
returned by the generalTime subsystem and will print a warning if the wall-clock
time returned has not been initialized yet. This is just a warning message; when
a time provider does synchonize the IOC will subsequently pick up and use the
correct time. This check code also primes the registered event system provider
if there is one so the <tt>epicsTimeGetEventInt()</tt> routine will work on IOCs
that ask for event time within an interrupt service routine.</p>
<p>The osiClockTime provider's synchronization thread (which is only used on
some embedded targets) will now poll the other time providers at 1Hz until the
first time it manages to get a successful timestamp, after which it will poll
for updates every 60 seconds as before.</p>
<p>The routine <tt>generalTimeGetExceptPriority()</tt> was designed for use by
backup (lower priority) time providers like the osiClockTime provider which do
not have their own absolute time reference and rely on other providers for an
absolute time source. This routine no longer implements the ratchet mechanism
that prevented the time it returned from going backwards. If the backup clock's
tick-timer runs fast the synchronization of the backup time provider would never
allow it to be corrected backwards when the ratchet was in place. The regular
<tt>epicsTimeGetCurrent()</tt> API still uses the ratchet mechanism, so this
change will not cause the IOC to see time going backwards.</p>
<h3>Microsoft Visual Studio builds</h3>
<p>The build configuration files for builds using the Microsoft compilers have
been updated, although there should be no noticable difference at most sites.
One extra compiler warning is now being suppressed for C++ code, <tt>C4344:
behavior change: use of explicit template arguments results in ...</tt> which is
gratuitous and was appearing frequently in builds of the EPICS V4 modules.</p>
<p>Cross-builds of the windows-x64 target from a win32-x86 host have been
removed as they don't actually work within the context of a single <tt>make</tt>
run. Significant changes to the build configuration files would be necessary for
these kinds of cross-builds to work properly, which could be done if someone
needs them (email Andrew Johnson before working on this, and see
<a href="http://stackoverflow.com/questions/5807647/how-do-you-compile-32-bit-and-64-bit-applications-at-the-same-time-in-visual-stu">
this stack-overflow answer</a> for a starting point).</p>
<h3>Bazaar keywords such as 'Revision-Id' removed</h3>
<p>In preparation for moving to git in place of the Bazaar revision control
system we have removed all the keywords from the Base source code.</p>
<h3>Linux systemd service file for CA Repeater</h3>
<p>Building this version of Base on a Linux system creates a systemd service
file suitable for starting the Channel Access Repeater under systemd. The file
will be installed into the target bin directory, from where it can be copied
into the appropriate systemd location and modified as necessary. Installation
instructions are included as comments in the file.</p>
<h2 align="center">Changes made between 3.15.3 and 3.15.4</h2>
<h3>New string input device support "getenv"</h3>
<p>A new "getenv" device support for both the stringin and lsi (long string
input) record types can be used to read the value of an environment variable
from the IOC at runtime. See base/db/softIocExit.db for sample usage.</p>
<h3>Build rules and DELAY_INSTALL_LIBS</h3>
<p>A new order-only prerequisite build rule has been added to ensure that
library files (and DLL stubs on Windows) get installed before linking any
executables, which resolves parallel build problems on high-powered CPUs. There
are some (rare) cases though where a Makefile has to build an executable and run
it to be able to compile code for a library built by the same Makefile. With
this new build rule GNUmake will complain about a circular dependency and the
build will probably fail in those cases. To avoid this problem the failing
Makefile should set <tt>DELAY_INSTALL_LIBS = YES</tt> before including the
<tt>$(TOP)/configure/RULES</tt> file, disabling the new build rule.</p>
<h3>IOC environment variables and build parameters</h3>
<p>The IOC now sets a number of environment variables at startup that provide
the version of EPICS Base it was built against (EPICS_VERSION_...) and its build
architecture (ARCH). In some cases this allows a single iocBoot/ioc directory to
be used to run the same IOC on several different architectures without any
changes.</p>
<p>There are also 3 new environment parameters (EPICS_BUILD_...) available that
C/C++ code can use to find out the target architecture, OS class and compiler
class it was built with. These may be useful when writing interfaces to other
languages.</p>
<h3>New implementation of promptgroup/gui_group field property</h3>
<p>The mechanism behind the "promptgroup()" field property inside a record type
definition has been changed. Instead of using a fixed set of choices,
the static database access library now collects the used gui group names
while parsing DBD information. Group names should start with a two-digit number
plus space-dash-space to allow proper sorting of groups.</p>
<p>The include file <tt>guigroup.h</tt> that defined the fixed set of choices
has been deprecated. Instead, use the conversion functions between index number
and group string that have been added to dbStaticLib.</p>
<p>When a DBD file containing record-type descriptions is expanded, any
old-style <tt>GUI_xxx</tt> group names will be replaced by a new-style
string for use by the IOC. This permits an older record type to be used with
the 3.15.4 release, although eventually record types should be converted by
hand with better group names used.</p>
<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 from the 3.14 branch between 3.15.3 and 3.15.4</h2>
<h3>NTP Time Provider adjusts to OS tick rate changes</h3>
<p>Dirk Zimoch provided code that allows the NTP Time provider (used on VxWorks
and RTEMS only) to adapt to changes in the OS clock tick rate after the provider
has been initialized. Note that changing the tick rate after iocInit() is not
advisable, and that other software might still misbehave if initialized before
an OS tick rate change. This change was back-ported from the 3.15 branch.</p>
<h3>Making IOC ca_get operations atomic</h3>
<p>When a CA client gets data from an IOC record using a compound data type such
as <tt>DBR_TIME_DOUBLE</tt> the value field is fetched from the database in a
separate call than the other metadata, without keeping the record locked. This
allows some other thread such as a periodic scan thread a chance to interrupt
the get operation and process the record in between. CA monitors have always
been atomic as long as the value data isn't a string or an array, but this race
condition in the CA get path has now been fixed so the record will stay locked
between the two fetch operations.</p>
<p>This fixes <a href="https://bugs.launchpad.net/epics-base/+bug/1581212">
Launchpad bug #1581212</a>, thanks to Till Strauman and Dehong Zhang.</p>
<h3>New CONFIG_SITE variable for running self-tests</h3>
<p>The 'make runtests' and 'make tapfiles' build targets normally only run the
self-tests for the main <tt>EPICS_HOST_ARCH</tt> architecture. If the host is
able to execute self-test programs for other target architectures that are being
built by the host, such as when building a <tt>-debug</tt> version of the host
architecture for example, the names of those other architectures can be added to
the new <tt>CROSS_COMPILER_RUNTEST_ARCHS</tt> variable in either the
<tt>configure/CONFIG_SITE</tt> file or in an appropriate
<tt>configure/os/CONFIG_SITE.&lt;host&gt;.Common</tt> file to have the test
programs for those targets be run as well.</p>
<h3>Additional RELEASE file checks</h3>
<p>An additional check has been added at build-time for the contents of the
configure/RELEASE file(s), which will mostly only affect users of the Debian
EPICS packages published by NSLS-2. Support modules may share an install path,
but all such modules must be listed adjacent to each other in any RELEASE files
that point to them. For example the following will fail the new checks:</p>
<blockquote><pre>
AUTOSAVE = /usr/lib/epics
ASYN = /home/mdavidsaver/asyn
EPICS_BASE = /usr/lib/epics
</pre></blockquote>
<p>giving the compile-time error</p>
<blockquote><pre>
This application's RELEASE file(s) define
EPICS_BASE = /usr/lib/epics
after but not adjacent to
AUTOSAVE = /usr/lib/epics
Module definitions that share paths must be grouped together.
Either remove a definition, or move it to a line immediately
above or below the other(s).
Any non-module definitions belong in configure/CONFIG_SITE.
</pre></blockquote>
<p>In many cases such as the one above the order of the <tt>AUTOSAVE</tt> and
<tt>ASYN</tt> lines can be swapped to let the checks pass, but if the
<tt>AUTOSAVE</tt> module depended on <tt>ASYN</tt> and hence had to appear
before it in the list this error indicates that <tt>AUTOSAVE</tt> should also be
built in its own private area; a shared copy would likely be incompatible with
the version of <tt>ASYN</tt> built in the home directory.</p>
<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>
Reference in New Issue View Git Blame Copy Permalink