re...
> > ...(It might not be so bad for the .dbd file to have its own version
> > number, so record-support could verify that it wasn't compiled against an
> > outdated header file.)
>
> Since this can be checked at compile time, it should. There's no need to
> have a runtime field for the dbd version in each record. If there was a
> general way to include something in the database definition like
>
> recordtype(record_type) {
> define(TAG, "value")
>
> which gets
>
> #define record_typeRecordTAG value
>
> in the header file, record support could easily check anything it wants to
> at compile time or runtime.
That's a good idea. It does seem silly to use a field for this purpose.
> > Anyway, I'm in favor of every record having a VERS field.
> > [...]
> > I think the device support's version number should also be available via
> > channel access.
>
> If there are two different versions of one record or device support running
> in parallel, their record type or DTYP must be different, so having a
> version field would be redundant.
That's true only if they're running in the same ioc. It's an advantage for end
users to be able easily to find out which version of record/device support
they're running, so they can tell tech support on the phone.
> Is it really wanted two have different IOCs running different versions of
> the same record or device support? (*Shudder*)
It's flat-out impossible to keep scores of ioc's with different maintenance
schedules on the same version of everything. We try pretty hard to do this; if
we tried much harder, we'd have no time at all for development.
You might be thinking of an EPICS installation in which one person has control,
builds once, and builds correctly. But with lots of EPICS installations
involving lots of custom records and device support continually being enhanced,
maintained by lots of people with different areas of expertise, there's plenty of
opportunity for mismatched .dbd's and record/device support modules. It happens
frequently enough to be a tech-support issue for us and it's sometimes a very
hard problem to diagnose. (The amazing thing, by the way, is that EPICS works
well in this free-for-all shared-development atmosphere--*much* better than
anything else I've seen or heard of. In fact, EPICS appears to have been
designed for this.)
Tim Mooney
- Navigate by Date:
- Prev:
RE: EPICS r3.13 field DESC length Jeff Hill
- Next:
Re: EPICS r3.13 fields RTYP/VERS Mark Rivers
- 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:
Bookmark to EPICS software distribution Bakul Banerjee
- Next:
Re: EPICS r3.13 fields RTYP/VERS Mark Rivers
- 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
|