The Darwin version of epicsEnvShow (in src/libCom/osi/os/Darwin/osdEnv.c) +now uses _NSGetEnviron() to get the pointer to the environment string +table.
+The existing routines used to hash strings have been replaced by a new pair -of functions that are prototyped in the epicsString.h header file:
- +The existing routines used to hash strings have been replaced by a new +pair of functions that are prototyped in the epicsString.h header file:
unsigned int epicsStrHash(const char *str, unsigned int seed); -unsigned int epicsMemHash(const char *str, size_t length, unsigned int seed); -+unsigned int epicsMemHash(const char *str, size_t length, unsigned int seed); -
The seed argument should normally be zero, but can be used to chain several -hash calculations together to create a single value from multiple strings or -memory buffers. The resulting value should be masked with the appropriate -number of bits for the desired hash width. These functions both use the same -algorithm, and on most CPUs should be faster that the previous hash functions -used in Base. Use epicsStrHash() on nil-terminated strings, epicsMemHash() if -the data might contain zero bytes.
+The seed argument should normally be zero, but can be used to chain +several hash calculations together to create a single value from multiple +strings or memory buffers. The resulting value should be masked with the +appropriate number of bits for the desired hash width. These functions both +use the same algorithm, and on most CPUs should be faster that the previous +hash functions used in Base. Use epicsStrHash() on nil-terminated strings, +epicsMemHash() if the data might contain zero bytes.
To dynamically load a new routine for use with the sub or aSub record types, -you also have to register the subroutines at runtime. You can use the EPICS -build system and the registerRecordDeviceDriver.pl script to write the necessary -code for you, you just have to create a .dbd file that declares the functions in -the library and add the derived .cpp file to the library sources. The product of -your build should be a LOADABLE_LIBRARY to ensure that the correct -linker commands are used.
+To dynamically load a new routine for use with the sub or aSub record +types, you also have to register the subroutines at runtime. You can use the +EPICS build system and the registerRecordDeviceDriver.pl script to write the +necessary code for you, you just have to create a .dbd file that declares the +functions in the library and add the derived .cpp file to the library +sources. The product of your build should be a LOADABLE_LIBRARY to +ensure that the correct linker commands are used.
After a shared library is loaded into the IOC using the new iocsh dlload command you will usually have to run the -lib_registerRecordDeviceDriver routine to register the components that -were mentioned in the .dbd file. After registration the functions can be found -as normal by setting the SNAM field of your sub or aSub record instances. Once -loaded, shared libraries cannot be unloaded again as there is no way to be sure -that some other part of the IOC doesn't still have a pointer to something inside -the module.
+lib_registerRecordDeviceDriver routine to register the components +that were mentioned in the .dbd file. After registration the functions can be +found as normal by setting the SNAM field of your sub or aSub record +instances. Once loaded, shared libraries cannot be unloaded again as there is +no way to be sure that some other part of the IOC doesn't still have a +pointer to something inside the module.Components provided by a shared library can include functions for sub and -aSub records, iocsh commands, time providers and sequence programs. Record and -device support code may be possible, but there are complications in creating the -.dbd file so we don't recommend it yet. It is possible to load libraries after -iocInit, but the code is not re-entrant so should only be used from the main -thread. Adding new record types or device support will not work after -iocInit.
+aSub records, iocsh commands, time providers and sequence programs. Record +and device support code may be possible, but there are complications in +creating the .dbd file so we don't recommend it yet. It is possible to load +libraries after iocInit, but the code is not re-entrant so should only be +used from the main thread. Adding new record types or device support will +not work after iocInit.The CA::put and CA::put_callback methods now use the native -type of the PV to determine which data type to use in all cases; earlier -versions looked at the Perl data type for single-valued PVs, but this was -truncating some double values into integers.
+The CA::put and CA::put_callback methods now use the +native type of the PV to determine which data type to use in all cases; +earlier versions looked at the Perl data type for single-valued PVs, but this +was truncating some double values into integers.
Added a routine generalTimeHighestCurrentName() which returns the name of the highest prority registered current time provider. Comparing this -with the name returned by generalTimeCurrentProviderName() permits an -alarm to be generated if an IOC is not able to use the time provider it was -designed to use. The General Time stringin device support keyword +with the name returned by generalTimeCurrentProviderName() permits +an alarm to be generated if an IOC is not able to use the time provider it +was designed to use. The General Time stringin device support keyword @TOPTCP has been added to make this name available in a database record.
-The following routines have been renamed, but the old name may still be used -since a macro with the old name has been added:
+The following routines have been renamed, but the old name may still be +used since a macro with the old name has been added:
---
+ +- -Old Name -New Name - -generalTimeCurrentTpRegister -generalTimeRegisterCurrentProvider - -generalTimeEventTpRegister -generalTimeRegisterEventProvider - -generalTimeCurrentTpName -generalTimeCurrentProviderName - -generalTimeEventTpName -generalTimeEventProviderName + +
+ +Old Name +New Name ++ +generalTimeCurrentTpRegister +generalTimeRegisterCurrentProvider ++ +generalTimeEventTpRegister +generalTimeRegisterEventProvider ++ +generalTimeCurrentTpName +generalTimeCurrentProviderName ++ + +generalTimeEventTpName +generalTimeEventProviderName +
The routine generalTimeCreateSyncTimer() was not useful in practice -due to time provider initialization issues, nor was its implementation protected -properly for use on SMP systems so it has been deleted. The deprecated and -empty synchronize() method from the epicsTime class has also gone.
+The routine generalTimeCreateSyncTimer() was not useful in +practice due to time provider initialization issues, nor was its +implementation protected properly for use on SMP systems so it has been +deleted. The deprecated and empty synchronize() method from the +epicsTime class has also gone.
RTEMS release 4.10 or newer is required. EPICS now uses -unified executive/malloc memory pools.
+RTEMS release 4.10 or newer is required. EPICS now uses unified +executive/malloc memory pools.
RTEMS stack sizes have been reduced. This allows more clients in -machines with limited memory.
+RTEMS stack sizes have been reduced. This allows more clients in machines +with limited memory.
RTEMS file descriptor allocation has been increased.
@@ -139,41 +156,45 @@ machines with limited memory.Record definitions can declare their own alias names along with the field values, or a separate alias statement can also be used:
--record(ai,"canonicalName") ++++alias("canonicalName","secondAlias")record(ai,"canonicalName") { alias("firstAlias") } -alias("canonicalName","secondAlias")
Aliases can only be created for records that have already been loaded by the -IOC, although they don't have to appear in the same .db file. A CA client can -discover that a record name is an alias by fetching its .NAME field, which will -always return the canonical name for the record. These new routines in the -dbStaticLib library handle aliases:
+Aliases can only be created for records that have already been loaded by +the IOC, although they don't have to appear in the same .db file. A CA client +can discover that a record name is an alias by fetching its .NAME field, +which will always return the canonical name for the record. These new +routines in the dbStaticLib library handle aliases:
-long dbCreateAlias(DBENTRY *pdbentry, const char *paliasName); ++++long dbDeleteAliases(DBENTRY *pdbentry);long dbCreateAlias(DBENTRY *pdbentry, const char *paliasName); int dbIsAlias(DBENTRY *pdbentry); int dbGetNAliases(DBENTRY *pdbentry) -long dbDeleteAliases(DBENTRY *pdbentry);
Aliases are located using the existing record instance API. Use dbIsAlias() to test whether a record is actually an alias or not. Aliasees can be deleted like record instances using dbDeleteRecord() -which will not delete the underlying record if the DBENTRY refers to the alias -(deleting a record instance does delete all its aliases though). The -dbDeleteAliases() routine deletes all aliases of the selected record, -and will return an error if used on an alias.
+which will not delete the underlying record if the DBENTRY refers to the +alias (deleting a record instance does delete all its aliases though). The +dbDeleteAliases() routine deletes all aliases of the selected +record, and will return an error if used on an alias. -Any out-of-tree tools that scan through all the records in the database using -dbFirstRecord() and dbNextRecord() may need modifying to avoid -duplicate processing of aliased record instances. Also note that the set of -info items for a record instance are not shared with its aliases, which each -have their own info item namespace.
+Any out-of-tree tools that scan through all the records in the database +using dbFirstRecord() and dbNextRecord() may need modifying +to avoid duplicate processing of aliased record instances. Also note that +the set of info items for a record instance are not shared with its aliases, +which each have their own info item namespace.
Supplied by Matt Rippa <mrippa@gemini.edu>. Should work for MVME2400, -too.
+Supplied by Matt Rippa <mrippa@gemini.edu>. Should work for +MVME2400, too.
A Current Time Provider reports the current wall-clock time if it is able to when asked; if it can't it says so, and the time subsystem will then ask -the next provider in its list and so on until someone replies with the time. +the next provider in its list and so on until someone replies with the time. Event Time providers are handled similarly, except that they are asked for the timestamp associated with a particular Time Event number rather than the current wall-clock time. The registered time providers can be listed using @@ -266,7 +287,7 @@ with Base can be found in the IOC Application Developers Guide for R3.14.10, sections 9.7 and 20.6. General Time was originally written by David H. Thompson and Sheng Peng at ORNL, subsequently worked on by Babak Kalantari and Timo Korhonen of PSI, and merged into Base by Peter Denison from Diamond. - Andrew Johnson provided input into the design at various points and made +Andrew Johnson provided input into the design at various points and made various code revisions after the merge.