Hi Michael,
On 2012-12-05 [email protected] wrote:
> 1. Is iocshRegisterCommon() defined to be idempotent (ie, safe to call
> repeatedly)?
I believe so.
> 2. Is what I'm trying to do below sane?
Yes, with the caveat that the 3.15.0.1 development release won't currently
allow it. I have been asked to make it possible again in the future though,
and I've been doing some thinking about how to do that. More about that issue
below...
> Loading a dynamically generated support module requires the following
> steps:
>
> 1. Load the .so file.
I assume you're using the dlload.dbd and dlload command that's already
included with Base for this step.
> 2. Load the .dbd file (dbLoadDatabase seems to serve).
>
> 3. Register the dbd functionality.
>
> Of course, step 3 is the tricky one. I've experimented by adding the
> appropriate <module>_registerRecordDeviceDriver.cpp to the support
> module's build and then dynamically invoking the generated
> <module>_registerRecordDeviceDriver function ... and everything seems to
> work, but I am worried by one small detail.
>
> The generated code, generated by registerRecordDeviceDriver.pl from the
> module's .dbd file, is straightforward enough, but it always includes a
> call to iocshRegisterCommon() which gets called at C++ static constructor
> initialisation time ... which means if I'm generating register functions
> for every support module *and* for my base IOC this function will be
> called repeatedly. I imagine there's no particular guarantee that this
> function is idempotent, is there?
It should be since all it does is register commands, and re-registering a
command with the same pointers merely rewrites the originally registered
pointer values. Doing that wastes a little bit of CPU time, but should have
no other effect unless you've already registered some *different* pointers
against one of the built-in command names.
> First of all, is this a sane approach for what I'm trying to achieve?
Yes, Dirk Zimoch says he has been using this method for some time at PSI.
> Secondly, is this safe at the moment? I've dug into iocshRegisterCommon
> and its calls, and its work seems to devolve to numerous calls to
> iocshRegister, which looks properly monotonic to me, so I'm encouraged to
> proceed.
Should be.
In 3.15.0.1 though the registerRecordDeviceDriver.pl script won't accept a
device() definition unless it has already seen the corresponding recordtype()
definition. The 3.14 version of that script used a rudimentary DBD file
parser which didn't care, but the 3.15 I replaced that parser with the full
DBD parser that I had developed for DBD processing. That parser code (like
the dbStatic library) stores device support data inside the record type to
which it applies, so without seeing the record type definition it can't accept
the device definition.
That's obviously a step backwards for dynamic loading though, so I will make
it possible to build and load device support modules dynamically in future
releases of 3.15.
> Could we perhaps make the fact that iocshRegisterCommon can safely be
> called repeatedly more explicit by applying the following patch?
I am reluctant to make that change for 3.14.12.3 now that we've published the
release candidate, especially since it's not an essential modification. It
might be worth writing up a HowTo for the wiki though, which shouldn't need to
be very long.
- Andrew
--
Computer science is as much about computers as astronomy is about
telescopes. -- Edsger Dijkstra
- Replies:
- RE: Registering DBD files and iocshRegisterCommon michael.abbott
- References:
- Registering DBD files and iocshRegisterCommon michael.abbott
- Navigate by Date:
- Prev:
Re: Converting raw to eng in a waveform Paul Sichta
- Next:
RE: Converting raw to eng in a waveform Hill, Jeff
- 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:
Registering DBD files and iocshRegisterCommon michael.abbott
- Next:
RE: Registering DBD files and iocshRegisterCommon michael.abbott
- 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
|