EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Why we can't extend the DSET or DRVET
From: Andrew Johnson <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Marty Kraimer'" <[email protected]>, "'Eric Norum'" <[email protected]>, "'Core-Talk'" <[email protected]>
Date: Thu, 20 Nov 2003 15:12:37 -0600
Jeff Hill wrote:
The device support interface is defined by the record type and not by the
device support module. So, in principal, if the record type decides to add a
new routine then this will work just fine with devices which follow the
rules and specify the proper number of entries for previous revisions of the
interface.

The only way for a record type to indicate what the device support interface is would be for it to provide a header file containing the struct dset definition, which would be in addition to the automatically generated header file. None of the existing record types do this.

Certainly there will be devices that break the rules, but perhaps there are
relatively few of them and they can be fixed. I admit that there would need
to be some research done to determine the magnitude of the problem.

The problem is that given the current situation there's no way to guarantee that we'll catch them all at compile time.

One way to allow the existing interface to improve would be to generate a
record specific device support entry table for use with future drivers from
information stored in the record's dbd file.

Actually, there already is a way of adding stuff to the generated header file, but it's not documented, and nothing is using it yet. I haven't pushed it because even if the records started to use it there would still be no way to force existing device support to do so (i.e. to generate a compile-time error if they don't).

Of course, another option would be to define a new device support interface
and allow the record to specify which interface is used.

Which is rather different in terms of workload from where we started this discussion, wanting to add one routine. I don't disagree with you that we need to define a new interface, but I think that's currently way down in the priority list.

- Andrew
--
There are 10 types of people in the world:
Those who understand binary, and those who don't.


References:
RE: Why we can't extend the DSET or DRVET Jeff Hill

Navigate by Date:
Prev: RE: Why we can't extend the DSET or DRVET Jeff Hill
Next: Re: Why we can't extend the DSET or DRVET Marty Kraimer
Index: 2002  <20032004  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: Why we can't extend the DSET or DRVET Jeff Hill
Next: Re: Why we can't extend the DSET or DRVET Marty Kraimer
Index: 2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·