Difference between revisions of "User talk:AndrewJohnson"
Line 23: | Line 23: | ||
* Address parser? or is that part of connection? | * Address parser? or is that part of connection? | ||
Kay | 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. | 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. | ||
Line 33: | Line 33: | ||
=== Software Registration === | === Software Registration === | ||
Replacement for registrar() which requires that the code implements a basic interface. Maybe this includes a | 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 === | === Redundancy Requirements === | ||
Goal: 5 second fail-over to backup system | Goal: 5 second for fail-over to a backup system | ||
Limit: 15 seconds | 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? |
Revision as of 22:53, 2 May 2005
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?