Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 9 Jan 2015 13:16:40 -0600

On 01/09/2015 04:04 AM, Ralph Lange wrote:
> Does anyone have a good idea how to straighten this out in a reasonable
> and compatible way?

The API between the device support and the record type code is
completely up to the record type; the current conventions that we're
used to are not fixed in stone. There is no reason why a record type
can't provide routines for its devices to call to set the value, or to
do anything else that a device support might want to do. The prototypes
for these routines would appear as CDEFs in the Record.dbd file.

A record type can even change the device-sets-PACT => asynchronous-I/O
convention if it wants to; there's no requirement that it follow that
model, although the record must have PACT set while it's waiting for the
asynchronous completion. Changing the lock-and-call-process convention
to signal I/O completion might be a bit harder to do but not impossible,
although the record processing completion must be done in thread context
to allow things like forward linking to work properly.

The DSET and the definitions of its first 4 functions (report, init,
initRecord, getIoIntInfo) are required by the IOC and I would recommend
sticking with using the DSET for calls into the device support, but a
new record type can add anything it likes beyond the first 4 functions.
I would also encourage new record types to define their DSET as a CDEF
in the .dbd file so device supports don't have to do that.

Changing how existing record types interface is a very different issue
though, and I would suggest that we start to consider developing a new
set of standard record types instead, keeping the old ones around for
compatibility.

- Andrew
-- 
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System