Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 26 Jun 2009 17:17:56 -0600

Moving the alarm definitions into the ca library tends to lock future expansion at the binary protocol level to whatever codes we choose now. The primary risk would be loss of alarm codes which fall out of favor as time goes on. Perhaps not that big of an issue.

Another option would be to add a new DBR_GRAPHIC_ENUM type to ca and the db which can transport all of the codes. There are several other situations where the DBR_GRAPHIC_ENUM related limits are causing troubles? Admittedly, maybe this isn’t really a convenient solution because certain client side applications would like to directly test the alarm code in an if statement against a compile time constant.

Moving stuff to the ca lib does also require recompilation of all of the client side applications. One could argue that with patch releases the shareable library upgrades can patch problems but perhaps we do not require recompilation of client side applications, but this rule is rarely followed with base patch releases of late.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Davidsaver, Michael
> Sent: Friday, June 26, 2009 12:10 PM
> To: [email protected]
> Subject: RE: Patch: Move alarm.h and rename alarmString.h
> 
> > -----Original Message-----
> > From: [email protected] [mailto:core-talk-
> > [email protected]] On Behalf Of Andrew Johnson
> > Sent: Friday, June 12, 2009 6:52 PM
> > To: Core-Talk
> > Subject: Patch: Move alarm.h and rename alarmString.h
> >
> > Michael Davidsaver suggests we make the changes in the attached patch,
> > which moves alarm.h from src/dbStatic to src/ca and puts the static
> > alarm strings into libca.
> >
> > We've never really got the alarm enums right; there are equivalent
> > definitions in src/db/menuAlarmStat.dbd which must match alarm.h, and
> > we currently have the header alarmString.h which currently
> > instantiates a global alarm string array into whatever file it's
> > included by.  This is used both internally (by catools and cap5) and
> > externally (by MEDM, ALH, etc).
> >
> > Unfortunately there are more alarm status string values than can be
> > transported by CA as a DBF_ENUM, and even if they could be this
> > wouldn't help very much given that the extended dbr_ types include a
> > stat field anyway.
> >
> > I have made some (not terribly satisfactory) changes in this area
> > since R3.14.10 but Michael's idea of putting the strings into libca
> > seems interesting.
> >
> > Please discuss...
> >
> > - Andrew
> > --
> > The best FOSS code is written to be read by other humans -- Harold
> > Welte
> 
> 
> A slight change w/ respect to the previous patch.  To prevent compilation
> problem with external tools an empty 'alarmString.h' is created in
> src/ca/, and defining epicsAlarmGLOBAL is not an error.  Both ALH (1.2.23)
> and MEDM (3.1.4) compile and run without modification.
> 
> Michael

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System