Future Development Ideas

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

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 and rebase Merge Proposals

The Launchpad active review page lists branches which have been proposed for merging. In some cases this code needs to be rebased onto the 3.15 branch.

Documentation

Lots we can do here:

Record Reference Manual

• Extend the DBD to HTML converter so we can move detailed record reference documentation into the record.dbd and/or record.c files. Should we attempt to embed the RRM text inside the DBD files? This relies on Andrew's compiled-dbd branch which contains the work done so far.

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

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.

Check the code coverage report from the Diamond Autotest Results for ideas on what code to tackle, although that hasn't been run for quite a while now.

Priority: Medium

IOC Test Framework in Perl

Once we have good test coverage for libCom we should look at IOC-level testing, including tests for individual record types. This needs code to start a soft IOC with a particular database file, make channel connections over CA and perform the necessary tests, then close down the IOC and clean up. Tests should be automated, i.e. generate TAP output and run under the standard Perl Test::Harness, as used by the 'make runtests' target.

Once the framework exists, write test programs for each core record type and device support. Look at the Soft-Test suite and implement those tests too, although a complete rewrite might be appropriate for them...

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.

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 might require a different target architecture, although if the amount of change is small enough it might be possible to use conditional compilation instead.

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

Database diagnostics

When an IOC is too busy to service CA, the engineers need a way to find out what records are causing the problem. Something like a dbSpy command might be helpful, which would keep a count of the records processed by each scan thread and give periodic reports. Would need to be designed carefully so it doesn't eat RAM or slow down the machine too much.

Other diagnostics could also be added: dbProcess rate, ...

Priority: Medium
Libs affected: db, dbStatic.

Record aliases in VDCT

EPICS Base R3.14.11 supported record aliases, but AFAIK VDCT still does not. Both preserving the aliases attached to a record loaded from a .db file, and providing creation and editing capabilities for them through the GUI. This is a Java programming task which will need prior communication with CosyLab.

RSRV Using EPICS_CAS_INTF_ Variables

Change the socket binding in rsrv to use the EPICS_CAS_INTF_ variable(s) so we can limit IOCs to a subset of the interfaces of the host it's running on.

Packagable Build System

The EPICS Build system currently does not distinguish between programs that are needed by IOC developers (e.g. dbToMenuH) and end-user programs (e.g. caget). We could divide our build targets into these very easily, which would make packaging EPICS Base much more straight-forward. This should be based on Michael's reorganized source branch, although that should have been merged into the 3.15 branch before the Codeathon.

I see the following separate packages:

End-user Binaries

• catools
• Shared libraries
• SoftIoc (relies on a DBD file though)

These could be installed into /usr/local from an RPM or equivalent packaging system.

Developer Tools

• flex, antelope binaries etc.
• static libraries
• DBD and header files
• Build system components

These could be packaged into a -devel RPM or equivalent.

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.

New Record Types

From Bob: Add record types - valve record, improved control records for PID and Lead/Lag (if we had a good process control guy to design the record).

Enhancements to PID should start from the most advanced implementation currently available, which is not the old PID record type from Base 3.13. There's a PID record in synApps, and there may be others available from other sites too.

Priority: Dalesio
Libs affected: (external app)

CA support for Array with Timebase

From Bob: Add a new dbr_type into the channel access database - new array that includes time base and offset at least. One that also supports up to 3 dimensions (or better n).

Priority: Dalesio
Libs affected: Many...

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 to make it secure.

The CA-over-TCP branch should form the basis of this work.

Libs affected: ca, cas, rsrv

Online Record Creation

It might be possible to add new record instances at runtime, although delete would need a change to the record interface to support. The tricky thing is to do this in a manner which is completely thread-safe since the dbBase structure does not have many locks, and adding them could significantly affect the speed of operation of the IOC.

Libs affected: dbStatic, db, misc

Conversion Code Clean-Up

The existing conversion routines (i.e. the fast and full versions in db) could be significantly cleaned up by using C++ templated functions. There would probably be minor savings in object code size, but major savings in terms of source code size and clarity.

Here's a more detailed description of how this could be done.

Libs affected: dbStatic, db

Tasks which are already under way

These tasks are already being worked on but may have stalled. They might be hard for someone else to take over at this stage.

Compiling DBD Files

A Perl implementation of the DBD file parser exists and provides working dbdToRecordH and dbdToMenuH scripts. The aim is to convert all DBD file information into C tables that get compiled into the IOC executable or its shared libraries, so the no DBD data has to be read it at initialization time.

With the DBD parser written in Perl, it will be easier to add new facilities to DBD files, such as new field types (see Variable Length Strings below).

The code is in the compiled-dbd branch.

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.

This work should be done in the compiled-dbd branch.

Libs affected: dbHost, all libs Registrar code.

DBE_PROPERTY event generation

Extend the DBD syntax to link all fields that contain property values with the fields that the property is supplied with, then have dbPut() post a DBE_PROPERTY monitor on those fields whenever the property value changes.

Libs affected: dbHost, dbStatic, db Waiting for: Perl DBD Processing

Link Support

See original proposal by ANJ, which needs to be modified to add notify interfaces.

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, ...

Device Status String Field

DESY want a string field in dbCommon for device support to post signal-specific status information to. Once we have variable-length string types it would be reasonable to add this (if not used/set it would only add one pointer to each record instance).

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.