f5b7693a58
Hostnames that begin with one or more digits were not being looked up by name, causing problems at BNL. This commit also changes the vxWorks implementation of hostToIPAddr() to use inet_aton() instead of inet_addr().
659 lines
23 KiB
HTML
659 lines
23 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
<title>EPICS Base R3.15.0.1 Release Notes</title>
|
|
</head>
|
|
|
|
<body lang="en">
|
|
<h1 align="center">EPICS Base Release 3.15.0.1</h1>
|
|
|
|
<p>
|
|
EPICS Base 3.15.0.x releases are not intended for use in production systems.</p>
|
|
|
|
<h2 align="center">Changes between 3.15.0.1 and 3.15.0.2</h2>
|
|
<!-- Insert new items immediately below here ... -->
|
|
|
|
<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->dpvt);
|
|
prec->dpvt = NULL;
|
|
}
|
|
|
|
long myAsubRoutine(aSubRecord* prec) {
|
|
if (!prec->cadr) {
|
|
/* check types of inputs and outputs */
|
|
if (prec->ftva != menuFtypeDOUBLE)
|
|
return 1; /* oops */
|
|
|
|
dpvt = malloc(42);
|
|
prec->cadr = &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 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 += <list of files to be cleaned>
|
|
|
|
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 soft device support modify the NORD field of a
|
|
waveform record they now also post a DBE_VALUE and DBE_LOG event, signalling the
|
|
array length change to any clients monitoring the NORD field. Input device
|
|
support routines should be modified to do this as well.</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) && EPICS_VERSION_INT < 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=<<i>facility</i>>" syntax for
|
|
displaying the facility, process name etc. in log viewers like the
|
|
<code>cmlogviewer</code>.</p>
|
|
|
|
<h3>
|
|
Reworked the epicsEvent C & 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 <top>/config directory and build compatibility rules and
|
|
variables, and various conversion documents.</p>
|
|
|
|
</body>
|
|
</html>
|