Difference between revisions of "Future Development Ideas"

From EPICSWIKI
(Added DBD Command registration)
 
(75 intermediate revisions by 3 users not shown)
Line 1: Line 1:
These are my notes for what I think we can/should add to V3 through an evolutionary process.  The ordering is probably vaguely right, but not necessarily that accurate.
These are projects that can/should be added to EPICS V3 using an evolutionary process.  The ordering is not necessarily accurate.




Line 5: Line 5:




== 3.14 Changes completed ==
== Tasks for the 2014 Codeathon ==


The following modifications are included in a R3.14.9 release.
These items are of particular interest to have completed before the 3.15.0.2 release in September 2014.


* Add epicsUnitTest routines to libCom which generate output in the Test Anything Protocol (TAP) format.
<blockquote>
* Convert the existing test programs in libCom/test to use epicsUnitTest routines, which automates these tests.
* Major overhaul of the calc expression parser with improved diagnostics and additional functionality.
* Enhancements to the Access Security parser to improve diagnostics.
* Support for 64-bit CPUs (solaris-sparc64, linux-x86_64).
* Issues with multiple threaded CA clients.
* Fix so the PV Gateway supports the alarm handler.


== 3.14 Changes needed "soon" ==
=== Bug Triage and Fixing ===


* Jeff: Enhance CALC to allow names to be included in the CALC expression.
See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug
triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.


== 3.15 Cleanup ==
=== Review Merge Proposals ===


3.15 already includes the Up change to the build system; the ramifications of this change have not been followed up completely though:
The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging.


* Provide a perl script for converting 3.14 apps to 3.15
=== Record Reference Manual ===
* Bring over latest templates from 3.14
* Implications for building extensions not worked out
* makeBaseExt.pl is probably no longer needed
* Install local RULES_BUILD files into a top level directory
** Use this dir instead of the configure/O.arch directories so that a <tt>make clean</tt> doesn't remove them...
* Change script installation rules (see ctlsys)


Ben's Async dbGetLinkCallback: Defer to an upgrade to the record support interface, later in the process.  Or maybe include a dbGetLinkCallback() with the private callback routine, and require new record types to use this. Talk to synApps about this (Tim).
Work has started on embedding the RRM text inside the record type DBD files, but most record types have still to be documented this way. See ANJ's [https://code.launchpad.net/~anj/epics-base/dbd2html DBD To HTML branch] which contains the work done so far.


Jeff: Multiple Master problem (non-EPICS changes to output values in a PLC or similar device). This could be resolved adding a new routine to the RSET that the device support calls back when it has a new raw ouptut value to back-propagate to the VAL field.  Currently done by setting PACT and calling the record's process routine to use its second-half processing only.  Again, talk to Tim about this.
=== Dynamic Array Support ===


Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.


== Documentation ==
=== More test programs ===


Lots to do here:
There are test programs in libCom/test which cover quite a lot of the libCom functionality, but they are by far from complete.  Writing test code is a very good way to learn the capabilities of the code being tested, and is not usually hard to to, so this would be a good "getting started" project. Specific tests include:


* Write a "Building EPICS" guide (chapter in AppDevGuide?)
* Tests for each of the Base record types and device support. This should be based on ANJ's [https://code.launchpad.net/~epics-core/epics-base/ioc-test-module/ IOC Test Module] branch so the tests can be written in Perl.
* Any parts of libCom which don't currently have tests in libCom/test (C code)
* Rewrite the tests from the epics-soft-test suite (C or Perl).
 
=== Convert makeBpt into Perl ===
 
The makeBpt tool in src/bpt generates non-linear break-point tables from data files.  A fair bit of the C code is concerned with parsing the input file.  There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code.  Maybe start this project by writing a program to test the output, then convert the C code into Perl.
 
=== Support for 64-bit integer fields ===
 
ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and may not work on all target architectures (in particular VxWorks). See ANJ to work on this.
 
</blockquote>
 
== Other Tasks which could be done now ==
 
These items can be worked on immediately as they do not depend on any other work to have been completed.
 
<blockquote>
 
=== Bug Triage and Fixing ===
 
See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug
triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.
 
=== Review Merge Proposals ===
 
The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging.
 
=== Documentation ===
 
Lots we can do here:
 
<blockquote>
 
==== Application Developers Guide ====
 
* Write a "Building and Porting EPICS" chapter
* Restructure the AppDevGuide to make it more accessible
* Restructure the AppDevGuide to make it more accessible
* Convert AppDevGuide into an OpenDocument Text file (keeping index markers)
** Combine the libCom and libCom/osi chapters
* Update the Record Reference Manual to 3.14 and beyond (generate tables automatically from DBD files?)
** Maybe have a separate section for all callable APIs
* Look at all the documentation we have and see what's missing
** Consider moving API documentation into the appropriate source files and using Doxygen or perldoc to extract it.
* Data Access, other new CA-related documentation...


==== Other Documents ====


== Compiling DBD Files ==
* Look at all the documentation we have and see what's missing


My Perl implementation of the DBD file parser is still in process, and I'm hoping to revive this development effort to convert all DBD file information into C tables that get compiled into the IOC executable.
=== VxWorks SMP Support ===


With this parser now being written in Perl, it will become easier to extend the new facilities that we implement, such as adding new field types (see Variable Length Strings below).
Recent versions of vxWorks (6.8+) support SMP but present a slightly different API that removes intLock() and taskLock(), and replaces taskVar with __thread variables.  The current OSD routines for vxWorks will need significant modification to work with the new APIs.  This will probably require creating a new OS-Class.


Can obviously only be done by someone with access to vxWorks 6.8 or later.


== IOCSH Command Registration ==
=== Extended Device Support ===


Add DBD file syntax to convert DBD file information into a C header file which declares the command functions (similar to how we do record types in the current code-base). This header would then be included by the C file that defines those functions, thus the C compiler would do the work of ensuring that the routine implemented actually matches the command that will call it.
Experience converting device support layers to Extended support exposed the need to clean up the extended interface, i.e. reduce the code duplication which is currently required since the record knows nothing about the device change.


The command information in the DBD file will also be useful for future versions of the IRMIS parser for st.cmd scripts, where we need to be able to tie the device support configuration commands into IRMIS' need to map hardware devices to record addresses.
Libs affected: db, rec.


=== More flexible Access Security ===


== PV Aliases ==
The AS design defines each field's security level in the record description, and limits us to only levels 0 and 1.  Some sites may want finer control over accesses: being able to put individual fields of a specific record into a different level, and having additional static levels (use a bitmask?) would help in a number of situations. It is not clear how much work this would entail though.


The ability to add aliases to existing records has already been demonstrated and is a desirable feature, although the implementation that goes into Base might be somewhat different.
Priority: Low<br>
Libs affected: dbStatic, db, as, ...


Jeff: Give CAS the ability to make use of a prefix for all PV names that gets stipped before passing them to the tool.  Not efficient to implement this on RSRV.
=== Authentication ===


From Ralph: Two or three institutes need a way to password-protect access to certain databases. The usual encryption libraries are freely available, but I guess this issue needs a lot more thinking. Granularity: by record, by connection = IOC, or centralised? Should the authentication last for the client's lifetime or should a short form (some security token or key) be sent with every CA data package?


== Named Soft Events ==
=== Secure CA ===


Add the ability to use an event name instead of a number in the EVNT field.  EVNT is currently a short, but we only allow soft event numbers to be 8 bits, so this allows us space to add a new set of event numbers for the named events.  Ideally the event names would not have to be declared in advance, although that does leave the possibility of typos causing havoc.
Secure channel access protocol - add SSL wrappers around CA's TCP connections to make them secure.


Libs affected: ca, cas, rsrv


== Unbundling ==
</blockquote>


Split Base into three or more independent modules.  Each module would have its own version number, and the modules can therefore each have an independent existance, although there would obviously be specific dependencies associated with particular versions.
== Things which can't be completed yet ==


If we adopt this, we should bundle working subsets of modules together and release the complete bundle as a tarfile.
These are tasks are waiting on other people or for other tasks to be completed before they can be finished, although there may be infrastructure to support them that can be worked on in parallel.


I see the unbundled modules as follows:
<blockquote>


=== Core ===
=== IOCSH Command Registration ===


Depends on: Nothing
Add DBD file syntax to convert DBD file information into a C header file which declares the command functions (similar to how we do record types in the current code-base).  This header would then be included by the C file that defines those functions, thus the C compiler would do the work of ensuring that the routine implemented actually matches the command that will call it.


These are the common parts used by everything:
The command information in the DBD file will also be useful for future versions of the IRMIS parser for st.cmd scripts, where we need to be able to tie the device support configuration commands into IRMIS' need to map hardware devices to record addresses.


* Build system
Libs affected: dbHost, all libs Registrar code.
* libCom & OSI layer
** Basic registry routines
** IOC shell
* Antelope
* Flex
* makeApp tool


=== Link Support ===


=== Channel Access Client ===
See original proposal by ANJ, which needs to be modified to add notify interfaces. This work is already under way, talk to ANJ.


Depends on: Core
Part of this development (June 2016) includes [[JSON Field Values]].


Jeff Hill's responsibility.
=== Array Field Support ===


* CA-specific build rules (probably none)
Make it easier to add array fields to record types without having to do as much coding in the record support.  See [http://www.aps.anl.gov/epics/core-talk/2007/msg00078.php Ben Franksen email] and the work done by Nick Rees at the 2009 Codeathon.
* CA client library
* CA Tools
* CA application makeApp templates


Libs affected: dbHost, dbStatic, db, rec.


=== Channel Access Server ===
=== Variable Length Strings ===


Depends on: Core, IOC
The BaseString C++ APIs and classes were developed on the cvs-trunk branch and are being used by Jeff Hill in his replacement IOC server. This interface can form the basis of a new variable length string type for use in the database in addition to DBF_STRING.


Jeff Hill's responsibility.
Libs affected: dbHost, dbStatic, db, ...


* CAS-specific build rules (probably none)
=== Alternate DB File Formats ===
* GDD
* The CAS server tool
* RSRV (the old CA server code)
* CAS application makeApp templates


There have been calls to be able to replace the existing DB file format with an XML-based format. Currently the DB file parser is too highly integrated into the process of record creation to easily add a second format, but it would be feasible to separate these two and hence allow an expat-based or similar parser to be written. This would probably require a close analysis and upgrade to the locking arrangements of the database.  Alternative to XML would be JSON, for which a parser is already being included in the jsonfm branch.


=== IOC ===
Libs affected: dbHost?, dbStatic.


Depends on: Core, CAC, CAS
=== New Record API ===


The rest is code that runs on the IOC.
These requests all need a significant change to the record support API.  They are also fairly closely related, so should be used as input into any new API that gets devised.


* IOC-specific build rules
<blockquote>
* Static and runtime database access
* Runtime database
* Standard record types
* Soft device support
* The registry (device, driver, record, function)
* IOC application makeApp templates


==== Asynchronous Gets (3.16++) ====


== Redundancy ==
From Tim Mooney: It would be great if an input link could initiate processing, and get a value that is known to be the result of that processing, even if
records to be processed are asynchronous.  Currently, a record that needs completion-qualified data must know how to trigger the processing that generates that data.


DESY funded project for Bob & John to add redundant control of remote I/O, allowing hot-spare backup IOCs.
From Ben Franksen: Implemented an asyncronous dbGetLinkCallback() routine.  To do this properly though needs an upgrade to the record support API, but maybe could be shoe-horned into the the existing API by adding a dbGetLinkCallback() with a private callback pointer, and we'd require new record types to use this.  What does this do to the device support interface though?  Implications need study.


Andrew's Comment: This should be part of the implementation of linkSupport which I proposed in detail many years ago.  The purpose of the "Compiling DBD Files" item above is to make extending the DBD file syntax easier to do in the future, which is a necessary part of that development.


== CA Event Filtering ==
==== Blocking Puts (3.16++) ====


LANSCE needs Time and Flavored Data to replace ancient VAXen.  Jeff's plan is to be able to attach an expression to a channel subscription, which is evaluated by the client's server thread to check each monitor event to determine whether to send it to this client or not.  This could use an enhanced CALC expression parser and evaluation routine to do the expression, we just need a better parser since the expression might include record names.  Discussion about how the values for the expression get saved such that they have the value at the time the data was pushed into the event queue; they might have changed since them.  Jeff's fixed size event that contains those expression value resolves that issue, but it is very restrictive in terms of flexibility.
From Tim Mooney: It would be nice to have a link attribute that could put, request processing, and wait for completion.  We have this capability now, in dbCaPutCallback(), but it's selectable only at DCT time.


The idea is for a version of the SEQ record where rather than a fixed delay, the second link would wait for the completion callback from the first link.  This should be possible today with a special record type, but Tim suggests it should be possible with any link field of any record type.


== Variable Length Strings ==
Andrew's Comment: This should be part of the implementation of linkSupport which I proposed in detail many years ago.  The purpose of the "Compiling DBD Files" item above is to make extending the DBD file syntax easier to do in the future, which is a necessary part of that development.


I'm already adding my new BaseString C++ classes to libCom, and I intend to create a set of C wrapper routines for the base class operations (started, currently incomplete).  This can form the basis of a new string type for use in the database in addition to the DBF_STRING.


==== Multiple Master problem (3.16++) ====


== Alternate DB File Formats ==
From Jeff: Changes to output values in a PLC or similar device initiated outside of the output record. This could be resolved adding a new routine to the RSET that the device support calls back when it has a new raw ouptut value to back-propagate to the VAL field.  Currently done by some devices that set PACT and call the record's process() routine to use its second-half processing only.


There are calls to replace the existing DB file format with an XML-based format.  Currently the DB file parser is too highly integrated into the process of record creation to be able to add a second format, but it would be feasible to separate these two and hence allow an expat-based or similar parser to be written.  This would probably require a close analysis and upgrade to the locking arrangements of the database.


Need to coordinate with VDCT folks, etc.
==== Records Can't Block (3.16++) ====


From Tim Mooney: I think almost half the code in the sscan record is devoted to
bookmarking. In the middle of some algorithm, the record needs to wait for external events; the only way back in is process(), and so the record has to
have a complicated arrangement of switches that get it back into the
algorithm it was executing, with enough state information to decide what to do
next. At the same time, the record must check to see if it's now processing
because of some out-of-band request from the user.  Normal and exceptional processing must, therefore, be mixed together in the switch
arrangement, and adding new behaviors to the record becomes a very hairy undertaking.


== Online Record Creation ==
But what the record would really like to do is just wait with its
context intact for events, and allow special() to release it from the wait
if the user has requested something that requires this.  I guess this means the record should include author-defined event types in the wait mask, and special() should be able to generate author-defined events.


With good database locking, it might be feasible to look at the ability to add new record instances at runtime, and maybe delete as well.  This would probably need a change to the record interface to initialize the new instances.


</blockquote>


== Dynamically Loaded Modules ==
=== Dynamically Loaded Modules (3.16++) ===


After converting the DBD load process into table registration, it should become easier to allow support modules (containing record types, device support and other drivers) to be discovered and loaded dynamically.  Unloading is a very different matter though, we don't have the shutdown facilities to allow that.
After converting the DBD load process into table registration, it should become easier to allow support modules (containing record types, device support and other drivers) to be discovered and loaded dynamically.  Unloading is a very different matter though, we don't have the shutdown facilities to allow that.


=== Atomic Operations through CA (3.16++) ===
This is related to the Asynch Gets issue above; implement Read-Write (Swap, permits semaphores), Process-Read and Write-Process-Read (Command/Response) as atomic operations available through Channel Access.


== ... ==
</blockquote>

Latest revision as of 19:51, 1 June 2016

These are projects that can/should be added to EPICS V3 using an evolutionary process. The ordering is not necessarily accurate.



Tasks for the 2014 Codeathon

These items are of particular interest to have completed before the 3.15.0.2 release in September 2014.

Bug Triage and Fixing

See the Launchpad bug tracker. Bug triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

Review Merge Proposals

The Launchpad active review page lists branches which have been proposed for merging.

Record Reference Manual

Work has started on embedding the RRM text inside the record type DBD files, but most record types have still to be documented this way. See ANJ's DBD To HTML branch which contains the work done so far.

Dynamic Array Support

Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.

More test programs

There are test programs in libCom/test which cover quite a lot of the libCom functionality, but they are by far from complete. Writing test code is a very good way to learn the capabilities of the code being tested, and is not usually hard to to, so this would be a good "getting started" project. Specific tests include:

  • Tests for each of the Base record types and device support. This should be based on ANJ's IOC Test Module branch so the tests can be written in Perl.
  • Any parts of libCom which don't currently have tests in libCom/test (C code)
  • Rewrite the tests from the epics-soft-test suite (C or Perl).

Convert makeBpt into Perl

The makeBpt tool in src/bpt generates non-linear break-point tables from data files. A fair bit of the C code is concerned with parsing the input file. There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code. Maybe start this project by writing a program to test the output, then convert the C code into Perl.

Support for 64-bit integer fields

ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and may not work on all target architectures (in particular VxWorks). See ANJ to work on this.

Other Tasks which could be done now

These items can be worked on immediately as they do not depend on any other work to have been completed.

Bug Triage and Fixing

See the Launchpad bug tracker. Bug triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

Review Merge Proposals

The Launchpad active review page lists branches which have been proposed for merging.

Documentation

Lots we can do here:

Application Developers Guide

  • Write a "Building and Porting EPICS" chapter
  • Restructure the AppDevGuide to make it more accessible
    • Combine the libCom and libCom/osi chapters
    • Maybe have a separate section for all callable APIs
    • Consider moving API documentation into the appropriate source files and using Doxygen or perldoc to extract it.

Other Documents

  • Look at all the documentation we have and see what's missing

VxWorks SMP Support

Recent versions of vxWorks (6.8+) support SMP but present a slightly different API that removes intLock() and taskLock(), and replaces taskVar with __thread variables. The current OSD routines for vxWorks will need significant modification to work with the new APIs. This will probably require creating a new OS-Class.

Can obviously only be done by someone with access to vxWorks 6.8 or later.

Extended Device Support

Experience converting device support layers to Extended support exposed the need to clean up the extended interface, i.e. reduce the code duplication which is currently required since the record knows nothing about the device change.

Libs affected: db, rec.

More flexible Access Security

The AS design defines each field's security level in the record description, and limits us to only levels 0 and 1. Some sites may want finer control over accesses: being able to put individual fields of a specific record into a different level, and having additional static levels (use a bitmask?) would help in a number of situations. It is not clear how much work this would entail though.

Priority: Low
Libs affected: dbStatic, db, as, ...

Authentication

From Ralph: Two or three institutes need a way to password-protect access to certain databases. The usual encryption libraries are freely available, but I guess this issue needs a lot more thinking. Granularity: by record, by connection = IOC, or centralised? Should the authentication last for the client's lifetime or should a short form (some security token or key) be sent with every CA data package?

Secure CA

Secure channel access protocol - add SSL wrappers around CA's TCP connections to make them secure.

Libs affected: ca, cas, rsrv

Things which can't be completed yet

These are tasks are waiting on other people or for other tasks to be completed before they can be finished, although there may be infrastructure to support them that can be worked on in parallel.

IOCSH Command Registration

Add DBD file syntax to convert DBD file information into a C header file which declares the command functions (similar to how we do record types in the current code-base). This header would then be included by the C file that defines those functions, thus the C compiler would do the work of ensuring that the routine implemented actually matches the command that will call it.

The command information in the DBD file will also be useful for future versions of the IRMIS parser for st.cmd scripts, where we need to be able to tie the device support configuration commands into IRMIS' need to map hardware devices to record addresses.

Libs affected: dbHost, all libs Registrar code.

Link Support

See original proposal by ANJ, which needs to be modified to add notify interfaces. This work is already under way, talk to ANJ.

Part of this development (June 2016) includes JSON Field Values.

Array Field Support

Make it easier to add array fields to record types without having to do as much coding in the record support. See Ben Franksen email and the work done by Nick Rees at the 2009 Codeathon.

Libs affected: dbHost, dbStatic, db, rec.

Variable Length Strings

The BaseString C++ APIs and classes were developed on the cvs-trunk branch and are being used by Jeff Hill in his replacement IOC server. This interface can form the basis of a new variable length string type for use in the database in addition to DBF_STRING.

Libs affected: dbHost, dbStatic, db, ...

Alternate DB File Formats

There have been calls to be able to replace the existing DB file format with an XML-based format. Currently the DB file parser is too highly integrated into the process of record creation to easily add a second format, but it would be feasible to separate these two and hence allow an expat-based or similar parser to be written. This would probably require a close analysis and upgrade to the locking arrangements of the database. Alternative to XML would be JSON, for which a parser is already being included in the jsonfm branch.

Libs affected: dbHost?, dbStatic.

New Record API

These requests all need a significant change to the record support API. They are also fairly closely related, so should be used as input into any new API that gets devised.

Asynchronous Gets (3.16++)

From Tim Mooney: It would be great if an input link could initiate processing, and get a value that is known to be the result of that processing, even if records to be processed are asynchronous. Currently, a record that needs completion-qualified data must know how to trigger the processing that generates that data.

From Ben Franksen: Implemented an asyncronous dbGetLinkCallback() routine. To do this properly though needs an upgrade to the record support API, but maybe could be shoe-horned into the the existing API by adding a dbGetLinkCallback() with a private callback pointer, and we'd require new record types to use this. What does this do to the device support interface though? Implications need study.

Andrew's Comment: This should be part of the implementation of linkSupport which I proposed in detail many years ago. The purpose of the "Compiling DBD Files" item above is to make extending the DBD file syntax easier to do in the future, which is a necessary part of that development.

Blocking Puts (3.16++)

From Tim Mooney: It would be nice to have a link attribute that could put, request processing, and wait for completion. We have this capability now, in dbCaPutCallback(), but it's selectable only at DCT time.

The idea is for a version of the SEQ record where rather than a fixed delay, the second link would wait for the completion callback from the first link. This should be possible today with a special record type, but Tim suggests it should be possible with any link field of any record type.

Andrew's Comment: This should be part of the implementation of linkSupport which I proposed in detail many years ago. The purpose of the "Compiling DBD Files" item above is to make extending the DBD file syntax easier to do in the future, which is a necessary part of that development.


Multiple Master problem (3.16++)

From Jeff: Changes to output values in a PLC or similar device initiated outside of the output record. This could be resolved adding a new routine to the RSET that the device support calls back when it has a new raw ouptut value to back-propagate to the VAL field. Currently done by some devices that set PACT and call the record's process() routine to use its second-half processing only.


Records Can't Block (3.16++)

From Tim Mooney: I think almost half the code in the sscan record is devoted to bookmarking. In the middle of some algorithm, the record needs to wait for external events; the only way back in is process(), and so the record has to have a complicated arrangement of switches that get it back into the algorithm it was executing, with enough state information to decide what to do next. At the same time, the record must check to see if it's now processing because of some out-of-band request from the user. Normal and exceptional processing must, therefore, be mixed together in the switch arrangement, and adding new behaviors to the record becomes a very hairy undertaking.

But what the record would really like to do is just wait with its context intact for events, and allow special() to release it from the wait if the user has requested something that requires this. I guess this means the record should include author-defined event types in the wait mask, and special() should be able to generate author-defined events.


Dynamically Loaded Modules (3.16++)

After converting the DBD load process into table registration, it should become easier to allow support modules (containing record types, device support and other drivers) to be discovered and loaded dynamically. Unloading is a very different matter though, we don't have the shutdown facilities to allow that.

Atomic Operations through CA (3.16++)

This is related to the Asynch Gets issue above; implement Read-Write (Swap, permits semaphores), Process-Read and Write-Process-Read (Command/Response) as atomic operations available through Channel Access.

Retrieved from "https://wiki-ext.aps.anl.gov/epics/index.php?title=Future_Development_Ideas&oldid=3813"