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: 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 10:49:31 -0600
Jeff Hill wrote:

I assume that the device and driver support would be handled the same way -
by adding a new routine at the end of the device and driver support entry
tables.

That's not possible because in reality the structure definition for the DSET is not defined centrally - it can be (and usually is) different for each record type, and is usually defined by the device support layer itself. For example, in R3.13 src/dev/atDev/devAt5Vxi.c contains two typedefs like this:

typedef struct {
        long            number;
        DEVSUPFUN       report;
        DEVSUPFUN       init;
        DEVSUPFUN       init_record;
        DEVSUPFUN       get_ioint_info;
        DEVSUPFUN       read_write;
        DEVSUPFUN       special_linconv;} AT5VXIDSET;

There are also several very commonly used device supports that have already extended the entry tables to add routines for their own purposes. One of the worst is devCommonGpib.h which contains this:

typedef struct {
  long          number;
  DEVSUPFUN     funPtr[20];
} gDset;

It would be impossible to insert a new routine into the struct dset defined in devSup.h without causing major headaches for years to come.

Similarly the driver support entry table gets defined and extended by individual drivers. This is the definition in drvBitBusInterface.h:

struct drvBitBusEt {
        long            number;
        DRVSUPFUN       report; /* Report status of Bit Bus links */
        DRVSUPFUN       init;   /* Init the xvme card */
        DRVSUPFUN       qReq;   /* Queue a transaction request */
};

I don't like the way these interfaces were designed, but there's not much we can do about them now if we're going to keep to the principle that any change we make in Base which breaks backwards comptibility must cause a compiler error rather than a runtime fault, which might be very subtle and hard to trace.

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


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

Navigate by Date:
Prev: Re: [EPICS Base R3.14.x 0000029]: Access Security host names should be case insensitive Marty Kraimer
Next: RE: Why we can't extend the DSET or DRVET Jeff Hill
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: [EPICS Base R3.14.x 0000029]: Access Security host names should be case insensitive Marty Kraimer
Next: RE: Why we can't extend the DSET or DRVET Jeff Hill
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 ·