Thanks for the historical background information. I can't claim to
understand all the details involved in the process, but after staring at
the code for a few days and experimenting with the planned additions, I
must say: the end result is not very pretty.
For instance, the functions in dbAccess.c like dbGet or getOptions take
a dbAddr* /and/ a db_field_log *pfl and if pfl is not NULL and not of
type dbfl_type_rec, use the members of the pfl, otherwise they use the
passed dbAddr. This considerably complicates these functions and the
case distinctions are strewn all over the place. There is also a certain
amount of duplication of some of the functionality of dbGet inside the
filters, notably in the array filter. Adding write filters in the same
way means even more code duplication, this time between dbPut and the
filters. This is not good.
I think what needs to be done here is to change (some of) the APIs. The
functions in dbAccess.c should /only/ take a db_field_log* as parameter
(which then must not be NULL). That means db_field_log either needs to
be extended to cover all of dbAddr, or it should even contain a full
dbAddr, at least in the case of dbfl_type_rec. Functions that call these
dbAccess routines and that only have a dbAddr at hand need to be changed
to wrap that dbAddr into a db_field_log before calling dbGet & co. This
can and should be encapsulated in a function, of course. Depending on
how dbAddr is embedded this may add some runtime overhead but I'd say
this is acceptable.
What we have instead is that the dbAddr is contained in the dbChannel.
So perhaps the first step should really be to move the dbChannel* into
the db_field_log (in case its type is dbfl_type_rec), as I suggested
previously.
We also need to define accessors to get at the relevant meta data inside
a db_field_log in a uniform manner. This could be done by adding macros,
similar to those in dbChannel.h. [Technical side note: Since these now
have to make a case distinction it would be *much* cleaner to add a
header file where we define an EPICS_INLINE macro that for compilers
that support C99 expands to the "inline" keyword and otherwise to MSVC's
"__inline"; and then use EPICS_INLINE functions for these accessors.]
This would have another benefit: a db_field_log would now be all that is
needed to run a filter. This would make it easier to write filters in a
symmetric way, i.e. such that they work in both directions. It would be
even better if we could get rid of dbfl_type_rec completely. However, to
make it easier to review the changes I think this should be done in a
separate second step.
I would appreciate comments before I start to work on this in anger.
Cheers
Ben
________________________________
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.
Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas Frederking
Sitz Berlin, AG Charlottenburg, 89 HRB 5583
Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin
Attachment:
pEpkey.asc
Description: application/pgp-keys
- Replies:
- Re: write to a single element of an array field Ben Franksen via Core-talk
- References:
- Re: write to a single element of an array field Ben Franksen via Core-talk
- Re: write to a single element of an array field Ben Franksen via Core-talk
- Re: write to a single element of an array field Ben Franksen via Core-talk
- Re: write to a single element of an array field Ralph Lange via Core-talk
- Re: write to a single element of an array field Johnson, Andrew N. via Core-talk
- Re: write to a single element of an array field Ralph Lange via Core-talk
- Navigate by Date:
- Prev:
Re: write to a single element of an array field Ben Franksen via Core-talk
- Next:
Bug in epicsMessageQueue? Mark Rivers via Core-talk
- 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:
Re: write to a single element of an array field Ben Franksen via Core-talk
- Next:
Re: write to a single element of an array field Ben Franksen via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|