Experimental Physics and Industrial Control System

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 problem is of course that many devices assume that the same device
support entry table is used for all records. However, it appears that on the
surface most of these devices will continue to work because they do not
define more routines than are defined by the records with which they
participate (AT5VXIDSET fits in this category). 

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.

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.

Similar comments apply to driver support.

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

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Thursday, November 20, 2003 9:50 AM
> To: Jeff Hill
> Cc: 'Marty Kraimer'; 'Eric Norum'; Core-Talk
> Subject: Why we can't extend the DSET or DRVET
> 
> 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 Andrew Johnson

Re: Why we can't extend the DSET or DRVET Marty Kraimer

References:

Why we can't extend the DSET or DRVET Andrew Johnson

Navigate by Date:

Prev: Why we can't extend the DSET or DRVET Andrew Johnson

Next: Re: Why we can't extend the DSET or DRVET Andrew Johnson

Index: 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: Why we can't extend the DSET or DRVET Andrew Johnson

Next: Re: Why we can't extend the DSET or DRVET Andrew Johnson

Index: 2002  <2003>  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024