Some more thoughts on hardware configuration. These thoughts
result from previous "grief" about hardware configuration
and the RAWL/RAWH E-mail discussion. This has been a topic
of discussion for several years but we could never develop
a consensus about what to do.
The following gives some thoughts on a possible approach
The existing 3.13 format for defining a recordtype is quite
adaquate for defining hardware specific values,
including configuration, diagnostic, and alarm info.
It should not be necessary to develop another syntax.
For the following discussion I use the term "hardware record".
I assume it has same syntax as existing 3.13 recordtype definition.
(We may have to add something to allow different levels of support.
Will ignore details like this for now.)
I think that the main issue to be decided before real progress can be made is:
What purposes does a hardware record serve?
One way to answer this question is to ask who
has access to a hardware record. I think only the following
should be considered:
1) Device/Driver support. This is why we are having this discussion!!!
2) Database Configuration Tools. Using the existing recordtype
syntax should allow all 3.13 DCTs to also process hardware records.
3) Channel Access/Database Access clients.
This is the root of the problem!!! The following are possible uses:
a) Provide device status.
b) Display raw values and other diagnostic information.
c) On line hardware add/delete/modification
The solution I have been advocating is to provide a full fledged
record support module for each device. This causes loud screams from
everyone who is responsible for implementing device/driver support.
I maintain that to provide all of the functions listed above it is
necessary to provide almost all the dbCommon fields and also almost all the
RSET functions. (We could, of course, invent an entirely new way of
handling hardware confuration. To get the functionality desired I bet
it will be at least as complicated to use as existing RSET methods).
Let me summarize:
dbCommon Fields:
NAME needed
DESC ?
scan fields Needed if want record to be scanned. Often not needed.
NOTE THAT THIS IS REALLY MANY MANY fields
alarm fields Needed if CA client
Lock Set
CA Pvt "
Access Sec "
RSET
report Probably not needed
init Sure seems nice
init_record Mandatory
process Often not needed. If not needed removes MUCH code.
special If want to know about changes. Needed for run time mods
get_value Obsolete
cvt_dbaddr If using arrays (Think of 16 channel adc)
get_array_info "
put_array_info "
get_units ? I think not necessary
get_precision Dont get me started about precision
get_enum_str Normally not necessary
get_enum_strs Normally not necessary
put_enum_str Normally not necessary
get_graphic_double ? I think not necessary
get_control_double ? I think not necessary
get_alarm_double ? I think not necessary
Now I will make a suggestion.
If we provide four types of run time support for hardware records
maybe we can satisfy all concerns:
Level 0: Just what we have today. Can only be used for devices that
need no configuration info except that provided by existing link types.
A caviot is that DCTs will not have "nice" access to this info.
Level 1: No run time support occurs. A record can still be created for
each device instance for configuration purposes. Note that even
simple VME devices will require such records because they need VME
resources. In addition such records must be provided if DCTs are needed to
report hardware configuration.
Level 2: CA run time support but no processing.
Level 3: Full blown RSET support just like now.
Comments?
Marty Kraimer
- Replies:
- Re: Hardware Configuration Ralph Lange
- Navigate by Date:
- Prev:
Re: RAWL/RAWH Marty Kraimer
- Next:
Re: Using g++ with 3.13 beta2 Jeff Hill
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: RAWL/RAWH Marty Kraimer
- Next:
Re: Hardware Configuration Ralph Lange
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|