EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: EPICS base V4: iocCore database: registrar, special
From: Benjamin Franksen <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Marty Kraimer <[email protected]>
Date: Wed, 23 Feb 2005 01:02:40 +0100
On Tuesday 22 February 2005 16:44, Andrew Johnson wrote:
> Marty Kraimer wrote:
> > Benjamin Franksen wrote:
> >> (2) The keyword "registrar" is obscure, IMO. Why not name it something
> >> like "function" (in accordance with keyword "variable")?
> >
> > What about this and also variable. What do we want to do for V4?
>
> A 'registrar' entry is used for any software that needs to be run at
> startup to register iocsh commands or perform other initialization.  It
> implies a particular operation that the named function must perform, and
> also requires the function's signature be
> 	void registrar(void);
> Note that the signature match is essential for use on Windows, which
> mangles the names.  I would be willing to rename the keyword if someone
> comes up with a better one, but I don't think 'function' is correct for
> that - it implies something a lot more generic than a registrar function.
>
> The 'variable' keyword is used to allow the named variables, usually
> debug variables, to be accessed (set) by the iocsh.

Ok, I completely misunderstood the meaning of 'registrar'. Just forget the 
suggestion, 'registrar' is ok for what it does.

> >> (3) record support's special
>
> Marty and I discussed this, and we agree that it could be better.  We
> think the best solution would be to require the special routine itself
> to be responsible for putting the value into the field; 

Yes.

> the pass 
> argument would go away, 

Yes.

> and instead the special routine be given the 
> dbAddr specifying the field and the value it's to be set to.  We also
> removed the argument from the field attribute special - if the field
> belongs to dbCommon the core libraries are responsible for doing the
> special processing, otherwise the record support will be called instead.

We should provide a library routine for the record support to call in order to 
perform the actual put to the field. I agree that it doesn't buy us anything 
to pass this routine as an argument.

Note that a complication arises due to the distinction between link fields 
(where dbPutString is used so that lock sets are re-calculated) and other 
fields (where dbPut is used which mainly performs the conversions).

Cheers,
Ben


References:
Re: EPICS base V4: iocCore database Marty Kraimer
Re: EPICS base V4: iocCore database Andrew Johnson

Navigate by Date:
Prev: Re: EPICS base V4: iocCore database: Booleans Benjamin Franksen
Next: Re: EPICS base V4: iocCore database: include/extend/expand Benjamin Franksen
Index: 2002  2003  2004  <20052006  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 V4 Eric Norum
Next: Re: EPICS base V4: iocCore database: include/extend/expand Benjamin Franksen
Index: 2002  2003  2004  <20052006  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 ·