User talk:AndrewJohnson

This page contains my notes from various meetings.

Notes

EPICS V4 Core

Interface Manager - need something to register and find interfaces.

• Could we generate a hash of the interface definition? Would allow us to compare interfaces and match two.

V4 Driver Interface

• Asyn Driver interfaces are now standardized, and are a good prototype for the V4 driver interface.
• In V4 the record types will directly talk to these driver interfaces.
• Hence device support will disappear in V4

Kay: These queryable interfaces are more like COM, although it seems that there is a difference in that in COM everything implements an interface that you can use to query what other interfaces an object implements.

We currently have interfaces for:

• value interface, for doing I/O and finding out about the value width, includes a "value changed" registration interface used for I/O Interrupt
• connection interface, for connecting/dis-connecting devices
• Address parser? or is that part of connection?

Kay: device support needs to be able to introspect the record it belongs to, to get the scan rate for instance, or the display limits. Solution: give the driver the record's name (or some other record pointer) to allow the driver to use the db access routines to get at this data.

However, don't try to include all of the asyn model into base.

Might use a record with a value field being a Map, which we then use for reading and/or writing device configuration data.

Software Registration

Replacement for registrar() which requires that the code implements a basic interface. Maybe this includes a reference counter, as well as reporting, interface queries?

Redundancy Requirements

Goal: 5 second for fail-over to a backup system

Limit: 15 seconds

Record Support Interface

Most of the existing RSET routines are associated with the CA server interface to records, which go away with Data Access.

Divide records into sub-structures with a named interface, but how to actually use that interface? Nobody has any code that can call through an interface that we don't know about until runtime. Therefor all these "structures with interface" need to implement routines in a standard interface.

Links: Is a link really a struct with a specific interface type? Maybe it's shorthand.

struct with interface name: since record type needs to know interface name to be able to call the interface, why is it being specified in the DBD file, rather than in an interface lookup inside the record code?

DA Vampire

Allow plugins that get inserted between the records and the CA server, in two places.

• A plugin can insert itself into the server event notification lists for indiviual fields and hence get called in the context of the db_post_event() call (or equivalent) inside the record's process routine.
• The plugin can also add properties to a record's property catalog (or even replace existing properties) and hence change the outside view of the record's fields.

SuperRecords

• Extract the hardware I/O functionality from the AI, BI, etc. records into separate objects that have associated code - init, delete, special, and multiple phases of process (which are named)
• Create a standard wrapper record type that can instanciate a single one of these objects into a record. At process time, this will execute each of the object's process routines in order.
• Be also able to instanciate one or more of these objects into a record type that has its own process routine, which can select which of the sub-object process routines to call in which order.

I agreed (with Bob) to look at this approach for the next core meeting, flesh out the implications for the DB internals etc., how easy would it be to implement this, what it will look like.

Hmm, code segments in the DBD file - can we put the super-record's process routine into the DBD file? Or extract DBD file information out of a .cpp file.

Coloured Beam Triggers

Permit a site to enhance the definition of the timestamp, adding an event bitmask field to the storage. The source of the timestamp (event system, TSEL, device support) can now fetch the beam colour as well as the current time. Events are named.

CA Event/Property discussion

We need to develop a table giving the standard events and the properties we expect to send on each event. This would help with understanding and discussions.

• Record and device support must no longer be allowed to write to CA-visible fields themselves; they must go through a wrapper that sets a bit in a bitmap that records a particular field has been changed.
• A record's process() routine starts by resetting the bitmap, then anything changed will be flagged, and at the end we call (something like the current) db_post_event() which notes all of the set bits and flags those changes up to the layer above. This only applies to "dynamic" property fields.
• Changes to record fields that are not "dynamic" only occur due to CA or DB puts; the act of changing the field also causes a db_post_event() for those changes.