epics/pcas
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity
Files
73eecbb759c2ff0185cb96f6cb8695d43981a4fb
pcas/documentation/RELEASE_NOTES.html
Andrew Johnson 73eecbb759 Merged ARCH and bind fixes from 3.14 branch, revno 12696
2017-01-23 17:20:51 -06:00

1566 lines
66 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.15.6 Release Notes</title>
</head>
<body lang="en">
<h1 align="center">EPICS Base Release 3.15.6</h1>
<p style="color:red">This version of EPICS Base has not been released yet.</p>
<h2 align="center">Changes made on the 3.15 branch since 3.15.5</h2>
<!-- Insert new items immediately below here ... -->
<h2 align="center">Changes from the 3.14 branch since 3.15.5</h2>
<!-- Insert inherited items immediately below here ... -->
<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>
<h2 align="center">Changes made between 3.15.2 and 3.15.3</h2>
<h3>Make the NTP Time provider optional on VxWorks</h3>
<p>Recent versions of VxWorks (sometime after VxWorks 6) provide facilities for
automatically synchronizing the OS clock time with an NTP server. The EPICS time
system used to assume that it had to provide time synchronization on VxWorks,
but now it tests for the existance of either of the two OS synchronization
threads before starting the NTP time provider. It is still possible to force the
NTP provider to be started even if the OS synchronization is running by defining
the environment variable <tt>EPICS_TS_FORCE_NTPTIME</tt> in the startup script
before loading the IOC's .munch file. Forcing may be necessary if the VxWorks
image is not correctly configured with the IP address of a local NTP server.</p>
<h3>Assembling files from numbered snippets</h3>
<p>A tool has been added that assembles file snippets specified on the
command line into a single output file, with sorting and replacing/adding of
snippets done based on their file names. The build system integration requires
the output file to be specified setting COMMON_ASSEMBLIES (arch independent)
or ASSEMBLIES (created by arch), then defining the snippets for each assembly
setting *_SNIPPETS (explicitly) or *_PATTERN (searched relative to all source
directories).
</p>
<h3>Clean up after GNU readline()</h3>
<p>If EPICS Base is built with readline support, any IOC that calls epicsExit()
from a thread other than the main thread is likely to leave the user's terminal
in a weird state, requiring the user to run something like 'stty sane' to clean
it up. This release patches the readline support code to clean up automatically
by registering an epicsAtExit() routine.</p>
<h3>Removed the last vestiges of RSET::get_value()</h3>
<p>The IOC has not called the get_value() routine in the RSET for a very long
time, but there was still one implementation left in the event record support
code, and a structure definition for one of the original arguments to that
routine was defined in recGbl.h. Both of these have now been removed.</p>
<h2 align="center">Changes made between 3.15.1 and 3.15.2</h2>
<h3>Raised limit on link field length in database files</h3>
<p>The length of INP/OUT link fields in database files was limited to 79 chars
by an internal buffer size in the db file parser. This limitation will go away
completely in 3.16, and has been statically raised to 255 chars for the 3.15
series.</p>
<h3>aoRecord raw conversion overflows</h3>
<p>The ao record type now checks converted raw values and limits them to the
32-bit integer range before writing them to the RVAL field. Previously value
overflows relied on Undefined Behaviour which could give different results on
different platforms. The ROFF fields of the ao and ai record types are now
DBF_ULONG to allow an ROFF setting of 0x80000000 to work properly.</p>
<h3>Changes to &lt;top&gt;/cfg/* files</h3>
<p>The order in which cfg/CONFIG* and cfg/RULES* files are included from support
applications listed in the configure/RELEASE* files has been changed. Previously
these files were included in the order in which the top areas are listed in the
RELEASE file, but it makes more sense to load them in reverse order since later
entries override earlier ones in Makefiles but the release file order is
supposed to allow earlier entries to take precedence over later ones. The same
change has been made to the inclusion of the &lt;top&gt;/configure/RULES_BUILD
files.</p>
<p>Two new file types can also be provided in a module's cfg directory. Files
named TOP_RULES* will be included by the top-level Makefile of other modules
that refer to this module; files name DIR_RULES* will be included by all
Makefiles that merely descend into lower-level directories. The cfg/RULES* files
are only included when make is building code inside the O.&lt;arch&gt;
directories.</p>
<p>The new cfg/DIR_RULES* file inclusion was designed to permit new recursive
make actions to be implemented by appending the name of the new action to the
ACTIONS variable. There must be a matching rule in one of the cfg/RULES* files
when doing this. Similar rules may also be defined in the cfg/TOP_RULES* and/or
cfg/DIR_RULES* files, but these should only state prerequisites and not directly
provide commands to be executed.</p>
<h3>Build rules for RTEMS GESYS modules</h3>
<p>RTEMS target builds can now be configured to make GESYS modules by changing
the <CODE>USE_GESYS=NO</code> setting in the file
configure/os/CONFIG_SITE.Common.RTEMS to <code>YES</code>.</p>
<h3>Added Make variables for command-line use</h3>
<p>The following variables are now used during the build process, reserved for
setting on the command-line only (Makefiles should continue to use the
<code>USR_</code> equivalents):</p>
<ul>
<li>CMD_INCLUDES</li>
<li>CMD_CPPFLAGS</li>
<li>CMD_CFLAGS</li>
<li>CMD_CXXFLAGS</li>
<li>CMD_LDFLAGS</li>
<li>CMD_DBFLAGS</li>
<li>CMD_DBDFLAGS</li>
<li>CMD_REGRDDFLAGS</li>
<li>CMD_ARFLAGS</li>
</ul>
<p>For example:</p>
<blockquote><pre>
make CMD_INCLUDES=/opt/local/include CMD_LDFLAGS=-L/opt/local/lib
</pre></blockquote>
<h3>Enhanced API for asTrapWrite listeners</h3>
<p>External software such as the CA Put Logging module that registers a listener
with the asTrapWrite subsystem was not previously given access to the actual
data being sent by the CA client. In most cases this was not a problem as the
listener can look at the field being modified both before and after the
operation, but if the put processes the record which immediately overwrites the
new value, the client's value cannot be observed.</p>
<p>This release adds three fields to the asTrapWriteMessage structure that is
passed to the listener routines. These new fields provide the CA data type, the
number of array elements, and a pointer to the source data buffer. This change
is completely backwards compatible with listener code written against the
original API. The new API can be detected at compile-time as follows:</p>
<blockquote><pre>
#include "asLib.h"
/* ... */
#ifdef asTrapWriteWithData
/* Enhanced API */
#endif
</pre></blockquote>
<h3>Use of PATH_FILTER in Makefiles deprecated</h3>
<p>The PATH_FILTER variable was being called to convert forward shashes
<tt><b>/</b></tt> in file paths into pairs of backward slashes
<tt><b>\\</b></tt> on Windows architectures. This has never been strictly
necessary, and was added about 10 years ago to get around some short-comings in
Windows tools at the time. All uses of PATH_FILTER in Base have now been
removed; the definition is still present, but will result in a warning being
printed if it is ever used.</p>
<h3>Using msi for dependencies</h3>
<p>To reduce confusion the msi program has been modified to allow the generation
of dependency rules by adding support for a <tt>-D</tt> option, and changing the
commands in RULES.Db to use this option instead of the mkmf.pl script. The new
build rules will not work with old versions of the msi program, so the command
variable name used in the rules has been changed from MSI to MSI3_15. Sites that
use a modified version of msi must provide support for both the <tt>-D</tt> and
<tt>-o&nbsp;outfile</tt> options, and should then point the MSI3_15 variable in
their applications' CONFIG_SITE files to that updated executable.</p>
<h2 align="center">Changes made between 3.15.0.2 and 3.15.1</h2>
<h3>epicsStrnEscapedFromRaw() and epicsStrnRawFromEscaped()</h3>
<p>These routines have been rewritten; the previous implementations did not
always behave exactly as specified.</p>
<h3>Shared Library Versions</h3>
<p>On architectures that can support it, the shared library version number for
libraries provided with Base has had the third component of the EPICS version
number added to it, thus libCom.so.3.15.1 instead of libCom.so.3.15. Windows
can only support two components to its internal product version number, and the
Darwin bug that external shared libraries were being built using the EPICS
version number has been fixed.</p>
<h3>Hooking into dbLoadRecords</h3>
<p>A function pointer hook has been added to the dbLoadRecords() routine, to
allow external modules such as autosave to be notified when new records have
been loaded during IOC initialization. The hook is called dbLoadRecordsHook and
follows the model of the recGblAlarmHook pointer in that modules that wish to
use it must save the current value of the pointer before installing their own
function pointer, and must call the original function from their own
routine.</p>
<p>The hook is activiated from the dbLoadRecords() routine and gets called only
after a database instance file has been read in without error. Note that the
dbLoadTemplates() routine directly calls dbLoadRecords() so this hook also
provides information about instantiated database templates. It is still possible
to load record instances using dbLoadDatabase() though, and doing this will not
result in the hook routines being called.</p>
<p>Code to use this hook should look something like this:</p>
<blockquote><pre>
#include "dbAccessDefs.h"
static DB_LOAD_RECORDS_HOOK_ROUTINE previousHook;
static void myRoutine(const char* file, const char* subs) {
if (previousHook)
previousHook(file, subs);
/* Do whatever ... */
}
void myInit(void) {
static int done = 0;
if (!done) {
previousHook = dbLoadRecordsHook;
dbLoadRecordsHook = myRoutine;
done = 1;
}
}
</pre></blockquote>
<p>As with many other parts of the static database access library there is no
mutex to protect the function pointer. Initialization is expected to take place
in the context of the IOC's main thread, from either a static C++ constructor or
an EPICS registrar routine.</p>
<h2 align="center">Changes made between 3.15.0.1 and 3.15.0.2</h2>
<h3>New iocshLoad command</h3>
<p>A new command <tt>iocshLoad</tt> has been added to iocsh which executes a
named iocsh script and can also set one or more shell macro variables at the
same time, the values of which will be forgotten immediately after the named
script finishes executing. The following example shows the syntax:</p>
<blockquote><pre>
iocshLoad "serial.cmd", "DEV=/dev/ttyS0,PORT=com1,TYPE=RS485"
iocshLoad "radmon.cmd", "PORT=com1,ADDR=0"
</pre></blockquote>
<h3>Support routines for 64-bit integers</h3>
<p>The libCom library now provides support for 64-bit integer types on all
supported architectures. The epicsTypes.h header file defines epicsInt64 and
epicsUInt64 type definitions for both C and C++ code. The epicsStdlib.h header
also declares the following for parsing strings into the relevent sized integer
variables: Functions epicsParseLLong(), epicsParseULLong() with related macros
epicsScanLLong() and epicsScanULLong(), and the functions epicsParseInt64()
and epicsParseUInt64(). Use the first two functions and the macros for long long
and unsigned long long integer types, and the last two functions for the
epicsInt64 and epicsUInt64 types. Note that the latter can map to the types long
and unsigned long on some 64-bit architectures such as linux-x86_64, not to the
two long long types.</p>
<p>This version does not provide the ability to define 64-bit record fields, the
use of the 64-bit types in the IOC database will come in a later release of
EPICS Base.</p>
<h3>Full support for loadable support modules</h3>
<p>Apparently later versions of Base 3.14 permitted support modules to be loaded
from a shared library at runtime without the IOC having been linked against that
shared library; the registerRecordDeviceDriver.pl program would accept a partial
DBD file containing just the entries needed for the library and generate the
appropriate registration code. In 3.15 however the registerRecordDeviceDriver.pl
program was replaced by one using the new DBD file parser, and in this a device
support entry would only be accepted after first loading the record type that it
depended on.</p>
<p>The parser has been modified to accept device entries without having seen the
record type first, although a warning is given when that happens. To remove the
warning the DBD file can provide a record type declaration instead (no fields
can be defined, so the braces must be empty), before the device() entry. The
result will generate the correct registration code for the device entry without
including anything for any merely declared record types. The generated code can
be linked into a shared library and loaded by an IOC at runtime using dlload.
</p>
<h3>Parallel callback threads</h3>
<p>The general purpose callback facility can run multiple parallel callback
threads per priority level. This makes better use of SMP architectures (e.g.
processors with multiple cores), as callback work - which includes second
stage processing of records with asynchronuous device support and I/O
scanned processing - can be distributed over the available CPUs.</p>
<p>Note that by using parallel callback threads the order of scan callback
requests in the queue is not retained. If a device support needs to be
informed when scanIoRequest processing has finished, it should use the new
scanIoSetComplete() feature to add a user function that will be called after
the scanIoRequest record processing has finished.</p>
<p>Parallel callback threads have to be explicitly configured, by default
the IOC keeps the old behavior of running one callback thread per priority.</p>
<h3>Merge MMIO API from devLib2</h3>
<p>Added calls to handle 8, 16, and 32 bit Memory Mapped I/O reads and writes.
The calls added include <tt><i>X</i>_iowrite<i>Y</i>()</tt> and
<tt><i>X</i>_ioread<i>Y</i>()</tt>
where <tt><i>X</i></tt> is <tt>nat</tt> (native), <tt>be</tt> or <tt>le</tt>,
and <tt><i>Y</i></tt> is <tt>16</tt> or <tt>32</tt>.
Also added are <tt>ioread8()</tt> and <tt>iowrite8()</tt>.</p>
<h3>Added optional dbServer API to database</h3>
<p>A server layer that sits on top of the IOC database may now register itself
as such by calling <tt>dbRegisterServer()</tt> and providing optional routines
that other components can use. The initial purpose of this API allows the Trace
Processing implementation in <tt>dbProcess()</tt> to identify a client that
causes a record to process when TPRO is set.</p>
<p>To support the client idenfication, the server provides a routine that
returns that identity string when called by one of its own processing
threads.</p>
<h3>Concatenated database definition files</h3>
<p>A series of database definition (dbd) files can now be concatenated during
the build process into a newly-created dbd file with result being installed into
$(INSTALL_LOCATION)/dbd without expanding it.</p>
<p>The following lines in an EPICS Makefile will create a file name.dbd in the
O.Common build directory containing the contents of file1.dbd followed by
file2.dbd then file3.dbd. The new file will then be installed into
$(INSTALL_LOCATION)/dbd without expanding any of its include statements.</p>
<blockquote><pre>
DBDCAT += name.dbd
name_DBD += file1.dbd file2.dbd file3.dbd
</pre></blockquote>
<p>The source files file1.dbd, file2.dbd and file3.dbd may be created by the
current Makefile, be located in the parent directory or any other directory in
the SRC_DIRS list, be specified by their full pathname, exist in the install dbd
directory, or be found in any dbd directory linked from the application's
RELEASE files.</p>
<h3>Posix: Drop SCHED_FIFO before exec() in child process</h3>
<p>If Base is compiled with <tt>USE_POSIX_THREAD_PRIORITY_SCHEDULING = YES</tt>
in configure/CONFIG_SITE or related files, the Posix implementation of the
libCom <tt>osiSpawnDetachedProcess()</tt> routine will switch the child process
to use the normal SCHED_OTHER (non real-time) scheduler before executing the
named executable program. If it needs to use the real-time scheduler the new
program can request that for itself.</p>
<h3>Posix: Lock all memory when running with FIFO scheduler</h3>
<p>On Posix systems, an IOC application's ability to meet timing deadlines is
often dependent on its ability to lock part or all of the process's virtual
address space into RAM, preventing that memory from being paged to the swap
area. This change will attempt to lock the process's virtual address space into
RAM if the process has the ability to run threads with different priorities. If
unsuccessful, it prints an message to stderr and continues.</p>
<p>On Linux, one can grant a process the ability to run threads with different
priorities by using the command <code>ulimit -r unlimited</code>. To use the
FIFO scheduler for an IOC, use a command like this:</p>
<blockquote><pre>chrt -f 1 softIoc -d test.db</pre></blockquote>
<p>On Linux, one can grant a process the ability to lock itself into memory
using the command <code>ulimit -l unlimited</code>. These limits can also be
configured on a per user/per group basis by changing /etc/security/limits.conf
or its equivalent.</p>
<p>A child process created via fork() normally inherits its parent's resource
limits, so a child of a real-time soft-IOC will get its parent's real-time
priority and memlock limits. The memory locks themselves however are not
inherited by child processes.</p>
<h3>Implement EPICS_CAS_INTF_ADDR_LIST in rsrv</h3>
<p>The IOC server can now bind to a single IP address (and optional port number)
read from the standard environment parameter EPICS_CAS_INTF_ADDR_LIST.
Additional addresses included in that parameter after the first will be ignored
and a warning message displayed at iocInit time.</p>
<h3>alarmString.h deprecated again</h3>
<p>The string arrays that provide string versions of the alarm status and
severity values have been moved into libCom and the header file that used to
instanciate them is no longer required, although a copy is still provided for
backwards compatibility reasons. Only the alarm.h header needs to be included
now to declare the epicsAlarmSeverityStrings and epicsAlarmConditionStrings
arrays.</p>
<h3>General purpose thread pool</h3>
<p>
A general purpose threaded work queue API epicsThreadPool is added.
Multiple pools can be created with controlable priority and number
of worker threads. Lazy worker startup is supported.</p>
<h3>Database field setting updates</h3>
<p>A database (.db) file loaded by an IOC does not have to repeat the record
type of a record that has already been loaded. It may replace the first
parameter of the <tt>record(type, name)</tt> statement with an asterisk
character inside double-quotes, <tt>"*"</tt> instead. Thus the following is a
legal database file:</p>
<blockquote><pre>record(ao, "ao1") {}
record("*", "ao1") {
field(VAL, 10)
}</pre></blockquote>
<p>Note that database configuration tools will not be expected to have to
understand this syntax, which is provided for scripted and hand-coded database
and template instantiation only. Setting the IOC's <tt>dbRecordsOnceOnly</tt>
flag also makes this syntax illegal, since its purpose is to prevent
multiply-defined records from being collapsed into a single instance.</p>
<h3>Added echo command to iocsh</h3>
<p>The single argument string may contain escaped characters, which will be
translated to their raw form before being printed (enclose the string in quotes
to avoid double-translation). A newline is always appended to the output, and
output stream redirection is supported.</p>
<h3>Added macro EPICS_UNUSED to compilerDependencies.h</h3>
<p>To prevent the compiler from warning about a known-unused variable, mark it
with the macro EPICS_UNUSED. On gcc and clang this will expand to
<tt>__attribute__((unused))</tt> to prevent the warning.</p>
<h3>User specified db substitution file suffix</h3>
<p>Per Dirk Zimoch's suggestion, a user specified db substitution file suffix is
now allowed by setting the variable SUBST_SUFFIX in a configuration directory
CONFIG_SITE file or in a Makefile before the include $(TOP)/configure/RULES
line. The default for SUBST_SUFFIX is <tt>.substitutions</tt></p>
<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.</p>
<h3>Added newEpicsMutex macro</h3>
<p>Internal C++ uses of <tt>new epicsMutex()</tt> have been replaced with a new
macro which calls a new constructor, passing it the file name and line number of
the mutex creation code. C code that creates mutexes has been using a similar
macro for a long time, but there was no equivalent constructor for the C++
wrapper class, so identifying a specific mutex was much harder to do.</p>
<h3>Post DBE_PROPERTY events automatically</h3>
<p>A new record field attribute "prop(YES)" has been added to identify fields
holding meta-data. External changes to these fields will cause a CA monitor
event to be sent to all record subscribers who have asked for DBE_PROPERTY
updates. Meta-data fields have been marked for all Base record types.</p>
<h3>errlogRemoveListener() routine changed</h3>
<p>Code that calls <tt>errlogRemoveListener(myfunc)</tt> must be modified to use
the new, safer routine <tt>errlogRemoveListeners(myfunc, &amp;pvt)</tt> instead.
The replacement routine takes a second argument which must be the same private
pointer that was passed to <tt>errlogAddListener()</tt> when adding that
listener. It also deletes all matching listeners (hence the new plural name) and
returns how many were actually deleted, whereas the previous routine only
removed the first listener that matched.</p>
<h3>Simplified generation of .dbd files</h3>
<p>The Perl script <tt>makeIncludeDbd.pl</tt> has been removed and the rules
that created an intermediate <tt><i>xxx</i>Include.dbd</tt> file from the
Makefile variable <tt>xxx_DBD</tt> have been modified to generate the target
<tt><i>xxx</i>.dbd</tt> file directly. This should simplify applications that
might have had to provide dependency rules for the intermediate files in 3.15.
Applications which provide their own <tt><i>xxx</i>Include.dbd</tt> source file
will continue to have it expanded as before.</p>
<h3>New Undefined Severity field UDFS</h3>
<p>A new field has been added to dbCommon which configures the alarm severity
associated with the record being undefined (when UDF=TRUE). The default value is
INVALID so old databases will not be affected, but now individual records can be
configured to have a lower severity or even no alarm when undefined. Be careful
when changing this on applications where the IVOA field of output records is
used, IVOA still requires an INVALID severity to trigger value replacement.</p>
<h3>New build target <q>tapfiles</q></h3>
<p>This new make target runs the same tests as the <q>runtests</q> target, but
instead of summarizing or displaying the output for each test script it creates
a <q>.tap</q> file inside the architecture build directory which contains the
detailed test output. The output file can be parsed by continuous integration
packages such as <a href="http://www.jenkins-ci.org/">Jenkins</a> to show the
test results.</p>
<h3>Array field double-buffering</h3>
<p>Array data can now be moved, without copying, into and out of the VAL field
of the waveform, aai, and aao record types by replacing the pointer in BPTR.
The basic rules which device support must follow are:</p>
<ol>
<li>BPTR, and the memory it is currently pointing to, can only be accessed
while the record is locked.</li>
<li>NELM may not be changed; NORD should be updated whenever the number of
valid data elements changes.</li>
<li>When BPTR is replaced it must always point to a block of memory large
enough to hold the maximum number of elements, as given by the NELM and
FTVL fields.</li>
</ol>
<h3>Spin-locks API added</h3>
<p>The new header file epicsSpin.h adds a portable spin-locks API which is
intended for locking very short sections of code (typically one or two lines of
C or C++) to provide a critical section that protects against race conditions.
On Posix platforms this uses the pthread_spinlock_t type if it's available and
the build is not configured to use Posix thread priorities, but otherwise it
falls back to a pthread_mutex_t. On the UP VxWorks and RTEMS platforms the
implementations lock out CPU interrupts and disable task preemption while a
spin-lock is held. The default implementation (used when no other implementation
is provided) uses an epicsMutex. Spin-locks may not be taken recursively, and
the code inside the critical section should be short and deterministic.</p>
<h3>Improvements to aToIPAddr()</h3>
<p>The libCom routine aToIPAddr() and the vxWorks implementation of the
associated hostToIPAddr() function have been modified to be able to look up
hostnames that begin with one or more digits. The epicsSockResolveTest program
was added to check this functionality.</p>
<h3>mbboDirect and mbbiDirect records</h3>
<p>These record types have undergone some significant rework, and will behave
slightly differently than they did in their 3.14 versions. The externally
visible changes are as follows:</p>
<h5>mbbiDirect</h5>
<ul>
<li>If the MASK field is set in a database file, it will not be over-written
when the record is initialized. This allows non-contiguous masks to be set,
although only the device support actually uses the MASK field.</li>
<li>If process() finds the UDF field to be set, the record will raise a
UDF/INVALID alarm.</li>
</ul>
<h5>mbboDirect</h5>
<ul>
<li>If the MASK field is set in a database file, it will not be over-written
when the record is initialized. This allows non-contiguous masks to be set,
although only the device support actually uses the MASK field.</li>
<li>After the device support's init_record() routine returns during record
initialization, if OMSL is <q>supervisory</q> and UDF is clear the fields
B0-BF will be set from the current VAL field.</li>
<li>When a put to the OMSL field sets it to <q>supervisory</q>, the fields
B0-BF will be set from the current VAL field. This did not used to happen,
the individual bit fields were previously never modified by the record.
Note that this change may require some databases to be modified, if they
were designed to take advantage of the previous behavior.</li>
</ul>
<h3>Redirection of the errlog console stream</h3>
<p>A new routine has been added to the errlog facility which allows the console
error message stream to be redirected from stderr to some other already open
file stream:</p>
<blockquote><pre>int errlogSetConsole(FILE *stream);
</pre></blockquote>
<p>The stream argument must be a FILE* pointer as returned by fopen() that is
open for output. If NULL is passed in, the errlog thread's stderr output stream
will be used instead. Note that messages to the console can be disabled and
re-enabled using the eltc routine which is also an iocsh command, but there is
no iocsh command currently provided for calling errlogSetConsole.</p>
<h3>Add cleanup subroutine to aSub record</h3>
<p>An aSub routine may set the CADR field with a function pointer which will be
run before a new routine in the event that a change to the SNAM field changes
the record's process subroutine.</p>
<p>This can be used to free any resources the routine needs to allocate. It can
also be used to determine if this is the first time this routine has been called
by this record instance. The CADR field is set to NULL immediately after the
routine it points to is called.</p>
<p>Example:</p>
<blockquote><pre>void cleanup(aSubRecord* prec) {
free(prec-&gt;dpvt);
prec-&gt;dpvt = NULL;
}
long myAsubRoutine(aSubRecord* prec) {
if (!prec-&gt;cadr) {
/* check types of inputs and outputs */
if (prec-&gt;ftva != menuFtypeDOUBLE)
return 1; /* oops */
dpvt = malloc(42);
prec-&gt;cadr = &amp;cleanup;
}
/* normal processing */
}
epicsRegisterFunction(myAsubRoutine);
</pre></blockquote>
<h3>Sequence record enhancements</h3>
<p>The sequence record type now has 16 link groups numbered 0 through 9 and A
through F, instead of the previous 10 groups numbered 1 through 9 and A. The
changes to this record are directly equivalent to those described below for the
fanout record. The fields OFFS and SHFT have been added and operate on the SELN
value exactly the same way. The result is backwards compatible with the 3.14
version of the sequence record as long as none of the new fields are modified
and the application does not rely on the SOFT/INVALID alarm that was generated
when the selection number exceeded 10. The record also now posts monitors on the
SELN field at the end of the sequence if its value changed when read through the
SELL link.
<h3>Fanout record enhancements</h3>
<p>The fanout record type now has 16 output links LNK0-LNK9 and LNKA-LNKF, plus
two additional fields which make the result backwards compatible with 3.14
databases, but also allow the link selection to be shifted without having to
process the SELN value through a calc or calcout record first.</p>
<p>Previously there was no LNK0 field, so when SELM is <q>Mask</q> bit 0 of SELN
controls whether the LNK1 link field was activated; bit 1 controls LNK2 and so
on. When SELM is <q>Specified</q> and SELN is zero no output link would be
activated at all; LNK1 gets activated when SELN is 1 and so on. Only 6 links
were provided, LNK1 through LNK6. The updated record type maintains the original
behavior when the new fields are not configured, except that the SOFT/INVALID
alarm is not generated when SELN is 7 through 15.</p>
<p>The update involved adding a LNK0 field, as well as fields LNK7 through LNK9
and LNKA through LNKF. To add flexibility and maintain backwards compatibility,
two additional fields have been added:</p>
<dl>
<dt><b>OFFS</b></dt>
<dd>This field holds a signed offset which is added to SELN to select which link
to activate when SELM is <q>Specified</q>. If the resulting value is outside the
range 0 .. 15 the record will go into a SOFT/INVALID alarm state. The default
value of OFFS is zero, so if it is not explicitly set and SELN is 1 the LNK1
link will be activated.</dd>
<dt><b>SHFT</b></dt>
<dd>When SELM is <q>Mask</q> the signed field SHFT is used to shift the SELN
value by SHFT bits (positive means right-wards, values outside the range -15 ..
15 will result in a SOFT/INVALID alarm), before using the resulting bit-pattern
to control which links to activate. The default value is -1, so if SHFT is not
explicitly set bit 0 of SELN will be used to control whether LNK1 gets
activated.</dd>
</dl>
<p>The record also now posts monitors on the SELN field if it changes as a
result of record processing (i.e. when read through the SELL link).</p>
<h3>Deleted Java build rules</h3>
<p>Java has its own build systems now, so we've deleted the rules and associated
variables from Base, although they might get added to the Extensions build rules
for a while in case anyone still needs them.</p>
<h2 align="center">Changes made between 3.14.x and 3.15.0.1</h2>
<h3>Application clean rules</h3>
<p>The <tt>clean</tt> Makefile target has changed between a single-colon rule
and a double-colon rule more than once in the life of the EPICS build rules, and
it just changed back to a single-colon rule, but now we recommend that
applications that wish to provide a Makefile that is backwards compatible with
the 3.14 build rules use the construct shown below. The 3.15 rules now support
a variable called <tt>CLEANS</tt> to which a Makefile can add a list of files to
be deleted when the user does a <tt>make clean</tt> like this:</p>
<blockquote><pre>CLEANS += &lt;list of files to be cleaned&gt;
ifndef BASE_3_15
clean::
$(RM) $(CLEANS)
endif</pre></blockquote>
<p>The conditional rule provides compatibility for use with the 3.14 build
system.</p>
<h3>MSI included with Base</h3>
<p>An enhanced version of the Macro Substitution and Include program <q>msi</q>
has been included with Base. Both this new version of msi and the IOC's
<tt>dbLoadTemplates</tt> command now support setting global macros in
substitution files, and <tt>dbLoadTemplates</tt> can now take a list of global
macro settings as the second argument on its command line. The substitution file
syntax is documented in the Application Developers Guide.</p>
<h3>Cross-builds targeting win32-x86-mingw</h3>
<p>Some Linux distributions now package the MinGW cross-compiler which makes it
possible to cross-build the win32-x86-mingw target from a linux-x86 host. Build
configuration files for this combination are now included; adjust the settings
in configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw and add win32-x86-mingw to
the CROSS_COMPILER_TARGET_ARCHS variable in configure/CONFIG_SITE or in
configure/os/CONFIG_SITE.linux-x86.Common.</p>
<h3>Architecture win32-x86-cygwin Removed</h3>
<p>The ability to compile non-cygwin binaries using the Cygwin build tools is no
longer supported by current versions of Cygwin, so this architecture has been
removed. Use the MinWG tools and the win32-x86-mingw architecture instead.</p>
<h3>RTEMS and VxWorks Test Harnesses</h3>
<p>The original libCom test harness has been renamed <tt>libComTestHarness</tt>,
and two additional test harnesses have been created <tt>dbTestHarness</tt> and
<tt>filterTestHarness</tt> which are all built for RTEMS and vxWorks targets.
The new ones include tests in src/ioc/db/test and src/std/filters/test.</p>
<p>Running the new tests requires additional .db and .dbd files to be loaded at
runtime, which can be found in the relevant source directory or its O.Common
subdirectory. If the target can access the Base source tree directly it may be
simplest to cd to the relevant source directory before running the test. If not,
the files needed are listed in the generated 'testspec' file found in the
associated build (O.<i>arch</i>) directory.</p>
<p>For RTEMS users the current directory is determined in a BSP specific way.
See rtems_init.c and setBootConfigFromNVRAM.c in src/libCom/RTEMS.</p>
<h3>New API to hook into thread creation</h3>
<p>A hook API has been added allowing user-supplied functions to be called
whenever a thread starts. The calls are made from the thread's context,
and can be used to control additional thread properties not handled inside
EPICS base, e.g. setting the scheduling policy or CPU affinity (on SMP
systems).</p>
<p>The API also supports a mapping operation, calling a user-supplied function
for every thread that is currently running.</p>
<h3>New scan rate units</h3>
<p>Scan rates defined in the menuScan.dbd file may now be specified in seconds,
minutes, hours or Hertz, and plural time units will also be accepted (seconds
are used if no unit is mentioned in the choice string). At <tt>iocInit</tt> each
scan rate is compared with the OS's clock tick and a warning printed if the
rate is too fast or likely to be more than 10% different to the requested rate.
For example the rates given below are all valid, although non-standard (the
default menuScan choices that come with Base have not been changed):</p>
<blockquote>
<pre>menu(menuScan) {
choice(menuScanPassive, "Passive")
choice(menuScanEvent, "Event")
choice(menuScanI_O_Intr, "I/O Intr")
choice(menuScan1_hour, "1 hour")
choice(menuScan0_5_hours, "0.5 hours")
choice(menuScan15_minutes, "15 minutes")
choice(menuScan5_minutes, "5 minutes")
choice(menuScan1_minute, "1 minute")
choice(menuScan10_seconds, "10 seconds")
choice(menuScan5_seconds, "5 seconds")
choice(menuScan2_seconds, "2 seconds")
choice(menuScan1_second, "1 second")
choice(menuScan2_Hertz, "2 Hertz")
choice(menuScan5_Hertz, "5 Hertz")
choice(menuScan10_Hertz, "10 Hz")
}</pre></blockquote>
<h3>Alarm filtering added to input record types</h3>
<p>The record types ai, calc, longin and mbbi have a new alarm filter added to
them. This provides a low-pass filter that can be used to delay the reporting of
alarms caused by the input level passing the HIGH, HIHI, LOW or LOLO values. The
filter is controlled with a new AFTC field that sets the filter's time constant.
The default value for this field is zero, which keeps the record's original
alarm behaviour.</p>
<p>The record must be scanned often enough for the filtering action to work
effectively and the alarm severity can only change when the record is processed,
but that processing does not have to be regular; the filter uses the time since
the record last processed in its calculation. Setting AFTC to a positive number
of seconds will delay the record going into or out of a minor alarm severity or
from minor to major severity until the input signal has been in that range for
that number of seconds.</p>
<h3>Post events on Waveform record's NORD field</h3>
<p>When the record type or device support modify the NORD field of a waveform
record, the record support code now posts DBE_VALUE and DBE_LOG events for that
field, signalling the array length change to any client monitoring the NORD
field.</p>
<h3>Attributes of Non-VAL Fields</h3>
<p>Non-VAL fields now report meaningful information for precision, units,
graphic limits, control limits, and alarm limits instead of simply using
PREC, EGU, HOPR, LOPR, DRVL, DRVH, HIHI, HIGH, LOW, and LOLO. All delay
fields have a default precision of 2 digits, units "s" and control limits
of 0 to 100,000 seconds (these precision and limit values can be changed
for each record type as a whole at runtime by updating a registered global
variable). Input fields like A-L of the calc record read their metadata
from the corresponding INPn link if possible.</p>
<h4>epicsStdioRedirect.h merged into epicsStdio.h</h4>
<p>The definitions from the header file epicsStdioRedirect.h have been moved
into epicsStdio.h so all calls to printf(), puts() and putchar() in files that
include that OSI header will now be subject to stdout redirection. In past
releases (3.14.7 and later) it was necessary to request the redirection support
by including the epicsStdioRedirect.h header file. The header file is still
provided, but now it just includes epicsStdio.h.</p>
<h4>Named Soft Events</h4>
<p>Soft events can now be given meaningful names instead of just using the
numbers 1-255. The EVNT field is now a DBF_STRING. The <tt>post_event()</tt> API
is now deprecated but still works. It should be replaced by code that in advance
looks up the <tt>EVNTPVT</tt> event handle associated with the named event by
calling <tt>eventNameToHandle(char *)</tt>, and when that event occurs passes
that handle to the new <tt>postEvent(EVNTPVT)</tt> routine (which may be called
from interrupt level). A new iocsh command <tt>postEvent <i>name</i></tt> will
trigger a named event from the command-line or a startup script (on vxWorks the
expression <tt>postEvent(eventNameToHandle("<i>name</i>"))</tt> must be used
instead though).</p>
<h4>Parallel Builds</h4>
<p>
As EPICS sites get computers with more CPUs they report additional bugs in our
parallel build rules. Various issues have been fixed by separating out the build
rules that generate dependency (.d) files, ensuring that they are constructed at
the appropriate time in the build.</p>
<p>
These rule changes can cause additional warning messages to appear when building
support modules. Where an application provides its own Makefile rules it may now
have to add rules to construct an associated dependency file. In many cases
though the change needed is just to replace a dependency for a
<tt>target$(OBJ)</tt> with the <tt>target$(DEP)</tt> so this</p>
<pre>
myLib$(OBJ): myLib_lex.c</pre>
<p>
becomes</p>
<pre>
myLib$(DEP): myLib_lex.c</pre>
<p>
To debug build issues assocated with dependency files, use the command <tt>make
--debug=m</tt> which tells GNUmake to display information about what it is doing
during the first pass when it updates its makefiles.</p>
<h3>
Removed tsDefs.h</h3>
<p>
The deprecated tsDefs API was provided for 3.13 compatibility only, and has now
been removed. Convert any remaining code that used it to call the epicsTime API
instead.</p>
<h3>
Changes to epicsVersion.h</h3>
<p>
The two macros <tt>EPICS_UPDATE_LEVEL</tt> and <tt>EPICS_CVS_SNAPSHOT</tt> have
been deleted from the epicsVersion.h file; they were deprecated in R3.14 and can
be replaced with <tt>EPICS_PATCH_LEVEL</tt> and <tt>EPICS_DEV_SNAPSHOT</tt>
respectively.</p>
<p>
A new pair of macros has been added to make version number comparisons easier.
Code that will not work with a version of Base before 3.15.0 can now be
written like this to prevent it from compiling:</p>
<pre style="margin: 0 2em;">
#if defined(VERSION_INT) &amp;&amp; EPICS_VERSION_INT &lt; VERSION_INT(3,15,0,0)
# error EPICS Base R3.15.0 or later is required
#endif
</pre>
<h3>
Added support for iocLogPrefix</h3>
<p>
Added a <code>iocLogPrefix</code> command to <code>iocsh</code>. This adds a
prefix to all messages from this IOC (or other log client) as they get sent to the
iocLogServer. This lets sites use the "fac=&lt;<i>facility</i>&gt;" syntax for
displaying the facility, process name etc. in log viewers like the
<code>cmlogviewer</code>.</p>
<h3>
Reworked the epicsEvent C &amp; C++ APIs</h3>
<ul>
<li>Renamed the enum epicsEventWaitStatus to epicsEventStatus</li>
<li>Defined epicsEventWaitStatus as a macro for epicsEventStatus</li>
<li>Renamed epicsEventWaitOk to epicsEventOk</li>
<li>Renamed epicsEventWaitError to epicsEventError</li>
<li>Defined epicsEventWaitOK and epicsEventWaitError as macros</li>
<li>Added epicsEventTrigger(id) which triggers an event and returns OK or an
error status if the underlying OS primitives report an error</li>
<li>Added epicsEventMustTrigger(id) which halts on error</li>
<li>Defined epicsEventSignal(id) as a macro for epicsEventMustTrigger(id)</li>
<li>Added a new C++ method epicsEvent::trigger() which throws an
epicsEvent::invalidSemaphore in the event of an error</li>
<li>epicsEvent::signal() makes an inline call to epicsEvent::trigger()</li>
<li>epicsEventWait() and epicsEventWaitWithTimeout() now return an error
status if the underlying OS primitives report an error</li>
<li>All the epicsEventMust...() routines are now implemented in the common
libCom/osi/epicsEvent.cpp source file, and call cantProceed() instead of
mis-using assert()</li>
<li>Implemented epicsEventShow() on Posix</li>
<li>Win32: Removed all epicsShareAPI decorations</li>
</ul>
<h3>
Enabled histogram record type</h3>
<p>
The histogram record was not included in the base.dbd file in any 3.14 release,
but has now been added along with its associated soft device support. The build
system now generates the list of all the record.dbd files in base automatically
in src/std/rec/Makefile.</p>
<h3>
Reorganization of src/</h3>
<p>Reorganization of subdirectories of src/ to better represent the relation
between different parts as described in the following table.</p>
<p>This change also allows the number of libraries built to be reduced to:
libCap5.so, libca.so, libdbCore.so, libdbStaticHost.so,
libCom.so, libcas.so, libdbRecStd.so, and libgdd.so</p>
<table border="1"><tbody>
<tr>
<th>Component</th>
<th>Dependency</th>
<th>Library name</th>
<th>Description</th>
</tr>
<tr>
<td>src/tools</td>
<td></td>
<td></td>
<td>Build system scripts</td>
</tr>
<tr>
<td>src/libCom</td>
<td>src/tools</td>
<td>Com</td>
<td>Utility routines and OS-independant API</td>
</tr>
<tr>
<td>src/template</td>
<td>src/tools</td>
<td></td>
<td>User application templates (e.g. makeBaseApp)</td>
</tr>
<tr>
<td>src/ca/client</td>
<td>src/libCom</td>
<td>ca</td>
<td>Channel Access client</td>
</tr>
<tr>
<td>src/ca/legacy/gdd</td>
<td>src/ca/client</td>
<td>gdd</td>
<td>Generic data layer for PCAS</td>
</tr>
<tr>
<td>src/ca/legacy/pcas</td>
<td>src/ca/legacy/gdd</td>
<td>cas</td>
<td>Portable Channel Access Server</td>
</tr>
<tr>
<td>src/ioc</td>
<td>src/ca</td>
<td>dbCore</td>
<td>Core database processing functions</td>
</tr>
<tr>
<td>src/std</td>
<td>src/ioc</td>
<td>dbRecStd</td>
<td>Standard records, soft device support and the softIoc </td>
</tr>
</tbody></table>
<p>
In order to better reflect these relations the following
directories and files were moved as described:</p>
<table border="1"><tbody>
<tr>
<th colspan="2">Relocations</th>
</tr>
<tr>
<th>Previous</th><th>New</th>
</tr>
<tr>
<th colspan="2">libCom</th>
</tr>
<tr>
<td>src/RTEMS</td>
<td>src/libCom/RTEMS</td>
</tr>
<tr>
<td>src/toolsComm/flex</td>
<td>src/libCom/flex</td>
</tr>
<tr>
<td>src/toolsComm/antelope</td>
<td>src/libCom/yacc</td>
</tr>
<tr>
<td align="right">src/dbStatic/alarm.h<br>.../alarmString.h</td>
<td>src/libCom/misc/</td>
</tr>
<tr>
<th colspan="2">IOC Core Components</th>
</tr>
<tr>
<td>src/bpt</td>
<td>src/ioc/bpt</td>
</tr>
<tr>
<td>src/db</td>
<td>src/ioc/db</td>
</tr>
<tr>
<td>src/dbStatic</td>
<td>src/ioc/dbStatic</td>
</tr>
<tr>
<td>src/dbtools</td>
<td>src/ioc/dbtemplate</td>
</tr>
<tr>
<td>src/misc</td>
<td>src/ioc/misc</td>
</tr>
<tr>
<td>src/registry</td>
<td>src/ioc/registry</td>
</tr>
<tr>
<td>src/rsrv</td>
<td>src/ioc/rsrv <a href="#rsrv">1</a></td>
</tr>
<tr>
<th colspan="2">Standard Record Definitions</th>
</tr>
<tr>
<td>src/dev/softDev</td>
<td>src/std/dev</td>
</tr>
<tr>
<td>src/rec</td>
<td>src/std/rec</td>
</tr>
<tr>
<td>src/softIoc</td>
<td>src/std/softIoc</td>
</tr>
<tr>
<th colspan="2">Channel Access</th>
</tr>
<tr>
<td>src/ca</td>
<td>src/ca/client</td>
</tr>
<tr>
<td>src/catools</td>
<td>src/ca/client/tools</td>
</tr>
<tr>
<td>src/cap5</td>
<td>src/ca/client/perl</td>
</tr>
<tr>
<td>src/gdd</td>
<td>src/ca/legacy/gdd</td>
</tr>
<tr>
<td>src/cas</td>
<td>src/ca/legacy/pcas</td>
</tr>
<tr>
<td>src/excas</td>
<td>src/ca/legacy/pcas/ex</td>
</tr>
<tr>
<th colspan="2">User Templates</th>
</tr>
<tr>
<td>src/makeBaseApp</td>
<td>src/template/base</td>
</tr>
<tr>
<td>src/makeBaseExt</td>
<td>src/template/ext</td>
</tr>
<tr>
<th colspan="2">Dispersed</th>
</tr>
<tr>
<td rowspan="3">src/util <a href="#util">2</a></td>
<td>src/ca/client</td>
</tr>
<tr>
<td>src/ca/client/test</td>
</tr>
<tr>
<td>src/libCom/log</td>
</tr>
<tr>
<td rowspan="2">src/as <a href="#as">3</a></td>
<td>src/libCom/as</td>
</tr>
<tr>
<td>src/ioc/as</td>
</tr>
</tbody></table>
<p><a name="rsrv">1</a>
RSRV is built as part of dbCore due to its tight (bidirectional) coupling
with the other database code.</p>
<p><a name="util">2</a>
The contents for src/util/ moved to three locations. The caRepeater init script
was moved to src/ca/client/. ca_test is now in src/ca/client/test/.
The iocLogServer was moved into the same directory (src/libCom/log) as
the log client code.</p>
<p><a name="as">3</a>
The Access Security code has been divided, with the parts not related to the
database (lexer/parser and trap registration) becoming part of libCom.
The remaining components are included in the dbCore library</p>
<h3>
Moved src/RTEMS/base directory</h3>
<p>
These files are now found under src/RTEMS.</p>
<h3>
Removed 3.13 compatibility</h3>
<p>
Removed the 3.13 &lt;top&gt;/config directory and build compatibility rules and
variables, and various conversion documents.</p>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink