705 lines
25 KiB
HTML
705 lines
25 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>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 but
|
|
falls back to a pthread_mutex_t if not; on the UP VxWorks and RTEMS platforms
|
|
the implementations lock out the CPU interrupts; the default implementation
|
|
(used where no better implementation is available for the platform) uses an
|
|
epicsMutex. Spin-locks may not be taken recursively, and the code inside the
|
|
critical section should always 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->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 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) && 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>
|