diff --git a/documentation/RELEASE_NOTES.html b/documentation/RELEASE_NOTES.html index 14326737a..610b6a4dc 100644 --- a/documentation/RELEASE_NOTES.html +++ b/documentation/RELEASE_NOTES.html @@ -58,27 +58,51 @@ integer types, so the new field types are presented to the CA server as (0x10_0000_0000_0000 = 4503599627370496) cannot be transported over Channel Access without their least significant bits being truncated. The EPICS V4 pvAccess network protocol can transport 64-bit data types however, and -a future release of the pvaSrv module will connect this ability to the IOC.
+a future release of the pvaSrv module will connect this ability to the fields of +the IOC. + +Additional 64-bit support will be provided in later release. For instance the +JSON parser for the new Link Support feature only handles integers up to +32 bits wide, so constant array initializer values cannot hold larger +values in this release.
+Add option EPICS_CA_MCAST_TTL to set the Time To Live (TTL) of any IP multi-cast -CA search or beacon packets sent.
+A new environment parameter EPICS_CA_MCAST_TTL is used to set the Time To +Live (TTL) value of any IP multi-cast CA search or beacon packets sent.
+-A new configuration environment variable EPICS_CA_AUTO_ARRAY_BYTES is used by libca and RSRV -(CA clients and IOC CA server). -The default EPICS_CA_AUTO_ARRAY_BYTES=YES removes the limitation of EPICS_CA_MAX_ARRAY_BYTES -and always attempts to allocate sufficient for a request. -The value of EPICS_CA_MAX_ARRAY_BYTES is ignored.> +
A new environment parameter EPICS_CA_AUTO_ARRAY_BYTES is now used by libca +and RSRV (CA clients and the IOC CA server). The default is equivalent to +setting EPICS_CA_AUTO_ARRAY_BYTES=YES which removes the need to set +EPICS_CA_MAX_ARRAY_BYTES and always attempts to allocate sufficiently large +network buffers to transfer large arrays properly over the network. In this case +the value of the EPICS_CA_MAX_ARRAY_BYTES parameter is ignored.
-Explicitly setting EPICS_CA_AUTO_ARRAY_BYTES=NO continues to honor EPICS_CA_AUTO_ARRAY_BYTES -as in previous releases.
+Explicitly setting EPICS_CA_AUTO_ARRAY_BYTES=NO will continue to honor the +buffer setting in EPICS_CA_AUTO_ARRAY_BYTES as in previous releases.
+ +The default setting for EPICS_CA_AUTO_ARRAY_BYTES can be changed by +adding the line
+ ++ ++EPICS_CA_AUTO_ARRAY_BYTES=NO +
to the configure/CONFIG_SITE_ENV file before building Base. Sites that wish +to override this only for specific IOC architectures can create new files for +each architecture named configure/os/CONFIG_SITE_ENV.<target-arch> with +the above setting in before building Base. The configuration can also be +explicitly changed by setting the environment variable in the IOC's startup +script, anywhere above the iocInit line.
+ +The PCAS server (used by the PV Gateway and other CA servers) now always +behaves as if EPICS_CA_AUTO_ARRAY_BYTES is set to YES (it ignores the +configuration parameter and environment variable).
-The PCAS server (used by cagateway) now always acts as if EPICS_CA_AUTO_ARRAY_BYTES=YES were -set.
This allows removal of UDP echo and similar protocol features which are not compatible with secure protocol design practice.
+The subArray record can now be used as a lookup-table from a constant array @@ -426,24 +451,24 @@ against older versions of base, such warnings are unavoidable.
Record types written in C++ need to take more drastic measures because of the stricter type checking in C++. To remain compatible with older versions -of base you need something like:
+of base you will need to use something like:#include "epicsVersion.h" #ifdef VERSION_INT -#if EPICS_VERSION_INT < VERSION_INT(3,16,0,2) -#define RECSUPFUN_CAST (RECSUPFUN) +# if EPICS_VERSION_INT < VERSION_INT(3,16,0,2) +# define RECSUPFUN_CAST (RECSUPFUN) +# else +# define RECSUPFUN_CAST +# endif #else -#define RECSUPFUN_CAST -#endif -#else -#define RECSUPFUN_CAST (RECSUPFUN) +# define RECSUPFUN_CAST (RECSUPFUN) #endif
and then replace (RECSUPFUN) with RECSUPFUN_CAST when initializing the rset. -Further changes might be needed, e.g. to adapt const-ness of +Further changes might also be needed, e.g. to adapt const-ness of method parameters.