Merge ~dirk.zimoch/epics-base:FilterForInfoFields into ~epics-core/epics-base/+git/epics-base:7.0

[Dirk Zimoch]

Add filter to read info fields

[Dirk Zimoch (dirk.zimoch)]

Works with R7.0.5 but stopped working after the merge with Ben's dbChannel refactoring). I am investigating why. It seems commit 85822f broke it.

review: Needs Fixing

[Dirk Zimoch (dirk.zimoch)]

The breaking change is in dbAccess.c line 918.

73fcbb5... by Dirk Zimoch on 2021-03-10

fail early for info field names that are empty or over the implementation limit of 50 chars

a461993... by Simon on 2021-03-10

Initial test

[Ben Franksen (bfrk)]

In case you haven't solved it yet: what exactly breaks?

[Ben Franksen (bfrk)]

Your branch compiles and tests fine on my machine.

[Ben Franksen (bfrk)]

Hm, I think my copy of your branch doesn't have the latest changes. I am on your branch but when I
git pull https://git.launchpad.net/~dirk.zimoch/epics-base FilterForInfoFields
it wants me to add a merge commit. I don't want to merge I want your branch as is. How do I do that?

[Ben Franksen (bfrk)]

And when I checkout the latest commit 663e6442e47ea7329217f60b6ca3e5c6d636620d on your branch it tells me I am not on any branch. Obviously I am having a bad git moment.

cfd0ea6... by Simon on 2021-03-10

Added more tests

bffda44... by Simon on 2021-03-10

Minor cleanup

1abb9c3... by Simon on 2021-03-10

Added one more type check test

74a3fa6... by Simon on 2021-03-10

Slight cleanup

[Dirk Zimoch (dirk.zimoch)]

I am at commit 663e6442e47ea7329217f60b6ca3e5c6d636620d which is based on 3ba778c08bfbf6364bdbefa41f16022b4c0f41d5, before your refactory was merged in.
I have not pushed the re-base on top of f571c5950bfe476ef79d4c143f50e2f9e0d5edc7.

What fails: I get garbage instead of the correct data. Don't know yet where it came from. I suspect it has to do with the new dbfl_has_copy() logic.

I could fix my code by adding a dummy pfl->u.r.dtor in order to claim "ownership" of the data for the logic in dbAccess.c. The desctructor does nothing, as the data does not need to be destroyed, but otherwise dbAccess.c takes a few wrong branches, it seems.

I have not analyzed the exact path of execution before and after. I have checked which your commits (cherry-picked onto my branch) broke my code and then which modified line. I got the first problem with commit 85822f in dbAccess.c line 918. Reverting that line restored my functionality. But later commits broke it again. So I checked what changed there.

I found out that adding a dtor seems to fix everything. I will commit than now and rebase this branch.

[Dirk Zimoch (dirk.zimoch)]

With the current 7.0 head, the function dbGet() in dbAccess.c branches 3 times on a test of dbfl_has_copy().

With a dummy dtor, the program flow it takes the else path all three times.
Without a dtor, it takes the first else path but the other two times it takes the if path.

In the old version of dbAccess.c, it took the else path all three times.

c5fe434... by Dirk Zimoch on 2021-03-10

fix for recent changes in dbGet()

[Ben Franksen (bfrk)]

I see the problem. What you are doing was not anticipated. You do not make a copy, the data is owned by the record all the time, so dbfl_has_copy correctly returns false. But then the code in dbAccess.c assumes that it has to ask the record for things like the actual number of elements etc, so it calls get_array_info for the dbAddr. For actual record fields this is precisely what we want. In your case I guess this is where things start to go wrong. Indeed you have set no_elements and field_type in the pfl. I am not sure how to fix this properly. Adding a dummy dtor means we lie to dbAccess, telling it we have made a copy in order to make it use the meta data in the pfl instead of trying to query the record about it. While this works I find it a bit obscure...

[Dirk Zimoch (dirk.zimoch)]

Yes, it is unexpected as I completely throw away the original data and replace it with a constant string. I am not happy to use such a lie, but it probably does no harm. It basically says: "It is my data, I care about the memory." Once we have code that modifies info fields at run time, I probably need a copy and a real descructor. And locks.

[Ben Franksen (bfrk)]

Here is what I think we should do. We add another member (one bit, no extra storage needed) to allow the filter to override the ownership decision made by dbfl_has_copy. We should also rename dbfl_has_copy to dbfl_is_owner to make this clearer. Then, instead of defining a dummy dtor, you can set pfl->is_owner = 1 and all is well. Like this:

diff --git a/modules/database/src/ioc/db/db_field_log.h b/modules/database/src/ioc/db/db_field_log.h
index e517d529f..68e725ed6 100644
--- a/modules/database/src/ioc/db/db_field_log.h
+++ b/modules/database/src/ioc/db/db_field_log.h
@@ -107,6 +107,7 @@ struct dbfl_ref {
  */
 typedef struct db_field_log {
     unsigned int type:1; /* type (union) selector */
+ unsigned int is_owner:1; /* whether we own the data */
     /* ctx is used for all types */
     unsigned int ctx:1; /* context (operation type) */
     /* the following are used for value and reference types */
@@ -131,8 +132,9 @@ typedef struct db_field_log {
  * this case, making a copy is redundant, so we have no dtor. But conceptually
  * the db_field_log still owns the (empty) data.
  */
-#define dbfl_has_copy(p)\
- ((p) && ((p)->type==dbfl_type_val || (p)->u.r.dtor || (p)->no_elements==0))
+#define dbfl_is_owner(p)\
+ ((p) && ((p)->type==dbfl_type_val || (p)->u.r.dtor || (p)->no_elements==0\
+ || (p)->is_owner))

 #define dbfl_pfield(p)\
  ((p)->type==dbfl_type_val ? &p->u.v.field : p->u.r.field)

[Ben Franksen (bfrk)]

Sorry, I sent this before I saw your reply. If you anticipate that you may need an actual dtor at some later point this may not be needed. Still, I like the idea to allow a filter to explicitly claim ownership, independent of the presence of a dtor. And renaming dbfl_has_copy to dbfl_is_owner is also probably a good idea.

[Ben Franksen (bfrk)]

I made a PR: https://github.com/epics-base/epics-base/pull/134

[mdavidsaver (mdavidsaver)]

Adding another member to db_field_log seems like the right approach. I'm wondering whether 'is_owner' is the right distinction to draw. While reviewing, I gave some consideration to adding 'must_lock' to indicate when dbScanLock is needed to for access. This avoids overloading the meaning of '!dtor'.

[Dirk Zimoch (dirk.zimoch)]

Your change looks backward compatible. Anyway, I have modified my code and re-based it.
I will force-push now...

[mdavidsaver (mdavidsaver)]

As I see it, there previously were three states for a db_field_log to be in:

1. Simple value type==dbfl_type_val
2. Owned value type==dbfl_type_ref
3. Borrowed value type==dbfl_type_rec

I think these would now need to be represented as:

1. type==dbfl_type_val && !dtor
2. type==dbfl_type_ref && dtor
3. type==dbfl_type_ref && dtor

Where 2 and 3 are ambiguous, and handling #2 would unnecessarily require dbScanLock()

Do I have this correct?

b7d2a43... by Simon on 2021-03-10

Refactor to reduce DRY

[Dirk Zimoch (dirk.zimoch)]

I had type==dbfl_type_ref && !dtor and own the value.

[Dirk Zimoch (dirk.zimoch)]

Ben wrote inline:
> + if (pfl->type == dbfl_type_ref && pfl->u.r.dtor)
> + pfl->u.r.dtor(pfl);
>
> These two lines seem to be unnecessary, since you always have type and dtor set to fixed values

What if two filters with dtors are chained?

[mdavidsaver (mdavidsaver)]

Maybe the assumption is that a value borrowed from a record will never need cleanup? Then:

1. type==dbfl_type_val && !dtor
2. type==dbfl_type_ref && dtor
3. type==dbfl_type_ref && !dtor

I'm not sure this is necessarily always true. I've been toying with the idea of involving db_field_log in reference counting where a record and and some db_field_log would share ownership. I haven't completely worked this through.

[Ben Franksen (bfrk)]

Am 10.03.21 um 17:49 schrieb Dirk Zimoch via Core-talk:
> Ben wrote inline:
>> + if (pfl->type == dbfl_type_ref && pfl->u.r.dtor)
>> + pfl->u.r.dtor(pfl);
>>
>> These two lines seem to be unnecessary, since you always have type and dtor set to fixed values
>
> What if two filters with dtors are chained?

Do they share the same pfl in this case? How would that work?

--
I would rather have questions that cannot be answered, than answers that
cannot be questioned. -- Richard Feynman

[Ben Franksen (bfrk)]

I am not sure I understand what you mean with "borrowed". IIUC there is nothing like that going on. You can have the value as a copy (dbfl_type_val) or as a reference (dbfl_type_ref). As I see it, the reference can be

1. owned by the record
2. owned the db_field_log

Originally I thought that 2 coincides with db_field_log having made a copy and thus having a dtor. For normal fields this is true. But info items are immutable, so there is no need to make a copy. There is also no need to to lock the record. And there is no need to query teh record for things like the current number of elements.

If there were guaranteed immutable record fields, the same would hold.

[Ben Franksen (bfrk)]

What happens when the record owns a reference and we lock it and then access the data can be called "borrowing". This is a temporary state and not a property of the db_field_log.

[Ben Franksen (bfrk)]

> I'm not sure this is necessarily always true. I've been toying with the idea of involving db_field_log in reference counting where a record and and some db_field_log would share ownership. I haven't completely worked this through.

I think I agree. This is why I proposed to allow the filter to override the conditional with an explicit "this is mine, keep off" bit.

[Ben Franksen (bfrk)]

Last remark for the moment. What we have with the info items here is that there is no actual owner. The decisions made in dbAccess when it calls dbfl_has_copy is about whether the meta data in the db_field_log is valid. Until now this happened to coincide with the data being owned by the db_field_log. It is clear that for a mutable array value the owner of the data is also the owner of the meta data (size, type, etc). But for immutable data that has no proper owner this is not obvious. So an alternative view would be to say that dbfl_has_copy == dbfl_is_owner stays as is and we add another property dbfl_has_meta_data that explicitly answers that particular question.

You alluded to possible shared ownership using reference counting. Let's see if I understand what you mean. So the actual data is immutable, but may be deallocated when the ref count goes to zero. The producer (normally the record) would create a fresh array but promise not to change the data after "publishing" it i.e. making it available as a field, nor the meta data. Then one could reference that data w/o locking. And since the db_field_log already has room for the meta data, the record (producer) could immediately create immutable reference counted db_field_logs. Was that the idea?

[mdavidsaver (mdavidsaver)]

> ... What if two filters with dtors are chained?

Since the value is being replaced, the original dtor needs to be called. So the basic process would be something like:

1. inspect previous value. eg. copy/convert etc.
2. dtor previous value
3. copy in new value/pointer and install new dtor

[mdavidsaver (mdavidsaver)]

> What happens when the record owns a reference and we lock it and then access the data can be called "borrowing". This is a temporary state and not a property of the db_field_log.

By "borrowed" I was meaning that a db_field_log which references a buffer which may only be accessed with a dbScanLock() of the associated record. Indeed struct db_field_log does not current encode this associate fully.

I think that you and I (Ben) probably have the same idea with only a sign flip in the name. Would you agree that "is_owner==!must_lock"? In your mind, does "is_owner" have a wider meaning than record locking? eg. does "is_owner" imply anything about the presence or absence of a dtor?

[Ben Franksen (bfrk)]

I don't think we disagree. I am fine with your definition "is_owner==!must_lock". But whether or not to lock (dbScanLock) is not the only question relevant here.

Immutable data does not have an owner: there is no need for any locking. Nevertheless (in the absence of garbage collection or ref counting) we must assign responsibility for deallocating the memory (unless the data remains life forever). This is signalled by a non-NULL dtor.

The other question is who has the relevant meta data? Again, for mutable data this is clearly the owner. For immutable data it could be the record or the field_log.

My refactor conflated all three notions: presence of a dtor == db_field_log is owner == db_field_log has the meta data. This is okay for mutable data but not for immutable.

The problem at hand, filters that allow to access info items, has these features: the data is immutable, so no owner; it has infinite life time, so there is no dtor; yet the meta data is held by the field_log, not the record.

This means we need another "degree of freedom": at least one extra bit, perhaps two. The design question is: precisely what meaning shall these bits have?

c99ede6... by Dirk Zimoch <email address hidden> on 2021-03-11

Merge pull request #1 from dirk-zimoch/FIFtest

Fi ftest

[Dirk Zimoch (dirk.zimoch)]

> > ... What if two filters with dtors are chained?
>
> Since the value is being replaced, the original dtor needs to be called. So
> the basic process would be something like:
>
> 1. inspect previous value. eg. copy/convert etc.
> 2. dtor previous value
> 3. copy in new value/pointer and install new dtor

Ok. That is what I'm doing:
1. Ignore the previous value
2. dtor it
3. copy new pointer and install new dtor.

That means those two line in question implement item 2 and need to stay.

6beea52... by Simon on 2021-03-11

'fixed' failing test

[Ben Franksen (bfrk)]

> 1. Ignore the previous value
> 2. dtor it
> 3. copy new pointer and install new dtor.
>
> That means those two line in question implement item 2 and need to stay.

I see. So this guards against a configuration error: someone applies the info item filter on top of some other filter. Such a configuration doesn't make sense, but we have to do something and I guess your solution is acceptable.

I would want to get a warning in this case, but certainly not every time the filter gets processed, rather only once when the filter is set up. Do you think that could be done?

b224fcf... by Simon on 2021-03-11

Using dbGet to fetch value

8a92bef... by Simon on 2021-03-11

Cleaned up source code and comments

[Dirk Zimoch (dirk.zimoch)]

Even though it makes no sense, it is totally leagal to do so. The two lines normally cost nothing because in the typical case dtor is NULL. Actually type is typically not even ref. But they prevent a memory leak in case someone does stack info ontop of another filter.

[Dirk Zimoch (dirk.zimoch)]

Simon's tests added.

[mdavidsaver (mdavidsaver)]

> ... I would want to get a warning in this case ...

I might agree if such a warning would be seen by a remote client. However, there isn't a mechanism for this. So rather, the IOC console would be cluttered up with messages saying the equivalent of "someone did this wrong". This doesn't seem so useful to me.

[Dirk Zimoch (dirk.zimoch)]

You mean like those:
dbChannelCreate: parse error: premature EOF
                                       {info:{n:"longinfo",l:1}
                     (right here) ------^

[mdavidsaver (mdavidsaver)]

Precisely. They are annoying, but in the case of errors acceptable as there is no alternative. I don't like the idea of extending this to warnings, where from the client prospective everything is working just fine.

[Andrew Johnson (anj)]

Some comments and questions inline; this also needs an entry in the documentation/ReleaseNotes.md file so people know the new filter exists.

review: Needs Fixing

[Dirk Zimoch (dirk.zimoch)]

Simon, please comment on the compiler flags.

5ef70f7... by Dirk Zimoch on 2021-03-12

revert link fixes

0d4063f... by Dirk Zimoch on 2021-03-12

info filter described in RELEASE_NOTES

f4b4a36... by Dirk Zimoch on 2021-03-12

debugging flags removed

50c9d70... by Dirk Zimoch on 2021-03-12

cleanup unneeded includes

[Dirk Zimoch (dirk.zimoch)]

I would like to have asyntax like TEST.{info:"infotag"} instead of TEST.{info:{name:"infotag"}} but unfortunately the filter plugin does not accept it.

[Ben Franksen (bfrk)]

> Precisely. They are annoying, but in the case of errors acceptable as there
> is no alternative. I don't like the idea of extending this to warnings, where
> from the client prospective everything is working just fine.

Hm, yes. A warning that's not seen by the one who causes it is perhaps not worth the hassle. So we have to be defensive here even though I don't like it.

[Dirk Zimoch (dirk.zimoch)]

Best I can achieve to have a long string "shortcut" is at the moment:
a) {info$:{n:"infotag"}}
b) {info:{n$:"infotag"}}
c) {info:{$:"infotag"}}

[mdavidsaver (mdavidsaver)]

The chfPlugin code would need to be taught about shortcuts. Maybe indicated for one parameter with a new bit flag in chfPluginArgDef?

[Dirk Zimoch (dirk.zimoch)]

First thing I changed in chfPlugin is to support arbitratily long string arguments, so that I do not need to limit the length of the tag name.
Should that change go to a different merge request?
Should it completely replace the fixed length "chfString" implementation? (currently only used in the "sync" filter)

[Andrew Johnson (anj)]

Can we keep any chfPlugin enhancements on a separate branch and as a separate PR please. If you mix them up you would be delaying the merge of the new filter and also complicating the review process, so separate is better. It would be okay to include modifications to streamline the existing filters in the PR that enhances the chfPlugin code.

You could include that suggested shortcut to the filter params here though, it looks much better than having the separate longstr parameter. I would also maybe use the shortcut in the Release Notes example, and even drop the quotes there so users who see it there start to recognize that the quotes aren't needed.

[Dirk Zimoch (dirk.zimoch)]

OK, I will create a separate branch for chfPlugin improvements.

Adding the shortcuts now and removeing the quotes from all examples.

[Dirk Zimoch (dirk.zimoch)]

Which shortcurt would you prefer for long string? {info:{name$:'name'}} or {info$:{name:'name'}} ?
As I am working on a change in chfPlugin to allow the even shorter {info:'name'}, info$ would probably be the better way to signal long string.

Should I drop the 'auto' mode?

[Ralph Lange (ralph-lange)]

+1 for info$

Which closely follows the initial idea behind the $ shortcut (cf. programming language Basic):
"Adding a $ makes it a string."

31b88eb... by Dirk Zimoch on 2021-03-15

cleanup quotes according to new JSON5 parser

ece87ca... by Dirk Zimoch on 2021-03-15

implement several shortcut alternatives

[Dirk Zimoch (dirk.zimoch)]

chfPlugin changes taken out and moved then to merge request 399636.

I fixed the usage of quotes in the documentation. I now suggest to use single quotes for string arguments and double quotes around the whole expression. (Basically because that allows to use shell features like $macros to be used within the double quotes).

I have added implementations for info$:{name:...} as well as for info:{name$:...}.
For me info$ looks nicer than name$ but name$ is simpler to implement.
But if I can implement the chfPlugin shortcut for 1 argument, then using info$ makes more sense.

[Dirk Zimoch (dirk.zimoch)]

review: Needs Information

[Dirk Zimoch (dirk.zimoch)]

If https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/399636 gets accepted, I would like to rebase this on top of that.
In that case, {info:'name'} for STRING and {info$:'name'} for CHAR array makes sense (no auto switching, no switching options).
Opinions?

[Andrew Johnson (anj)]

Core Group 8/11: Approve to be merged (without the chfPlugin changes which need more review).

review: Approve

[Andrew Johnson (anj)]

This Launchpad PR was approved last August buf "without chfPlugin changes", it may need rebasing in which case moving it over to GitHub would be worth doing first.

Unmerged commits

ece87ca... by Dirk Zimoch on 2021-03-15

implement several shortcut alternatives

31b88eb... by Dirk Zimoch on 2021-03-15

cleanup quotes according to new JSON5 parser

50c9d70... by Dirk Zimoch on 2021-03-12

cleanup unneeded includes

f4b4a36... by Dirk Zimoch on 2021-03-12

debugging flags removed

0d4063f... by Dirk Zimoch on 2021-03-12

info filter described in RELEASE_NOTES

5ef70f7... by Dirk Zimoch on 2021-03-12

revert link fixes

8a92bef... by Simon on 2021-03-11

Cleaned up source code and comments

b224fcf... by Simon on 2021-03-11

Using dbGet to fetch value

6beea52... by Simon on 2021-03-11

'fixed' failing test

c99ede6... by Dirk Zimoch <email address hidden> on 2021-03-11

Merge pull request #1 from dirk-zimoch/FIFtest

Fi ftest

diff --git a/documentation/RELEASE_NOTES.md b/documentation/RELEASE_NOTES.md
index 49cdd74..789a2ea 100644
--- a/documentation/RELEASE_NOTES.md
+++ b/documentation/RELEASE_NOTES.md
@@ -17,6 +17,15 @@ should also be read to understand what has changed since earlier releases.
 
 <!-- Insert new items immediately below here ... -->
 
+### New channel filter for info fields
+
+A new filter `info` is available to access info fields of a record
+using Channel Access or links.
+The text value can be read as a `DBF_STRING` or an array of `DBF_CHAR`.
+
+```
+caget 'recordname.{info:{name="infotag"}}'
+```
 
 -----
 
diff --git a/modules/database/src/std/filters/Makefile b/modules/database/src/std/filters/Makefile
index ee6a0ae..16e8171 100644
--- a/modules/database/src/std/filters/Makefile
+++ b/modules/database/src/std/filters/Makefile
@@ -16,6 +16,7 @@ dbRecStd_SRCS += dbnd.c
 dbRecStd_SRCS += arr.c
 dbRecStd_SRCS += sync.c
 dbRecStd_SRCS += decimate.c
+dbRecStd_SRCS += info.c
 
 HTMLS += filters.html
 
diff --git a/modules/database/src/std/filters/filters.dbd.pod b/modules/database/src/std/filters/filters.dbd.pod
index 27e356f..d171cda 100644
--- a/modules/database/src/std/filters/filters.dbd.pod
+++ b/modules/database/src/std/filters/filters.dbd.pod
@@ -16,6 +16,8 @@ The following filters are available in this release:
 
 =item * L<Decimation|/"Decimation Filter dec">
 
+=item * L<Info Field|/"Info Field Filter info">
+
 =back
 
 =head2 Using Filters
@@ -27,13 +29,11 @@ to the resulting data-stream.
 The filter specification must appear after the field name, or if the default
 (VAL) field is used after a dot C<.> appended to the record name.
 With the exception of the array short-hand which is described below, all filters
-must appear inside a pair of braces C< {} > after the dot expressed as a JSON
-(L<JavaScript Object Notation|http://www.json.org/>) object, which allows filter
-parameters to be included as needed.
+must appear inside a pair of braces C< {} > after the dot expressed as a JSON5
+(L<JavaScript Object Notation|https://spec.json5.org/>) object, which allows
+filter parameters to be included as needed.
 
-Each filter is given as a name/value pair. The filter name (given in parentheses
-in the titles below) is a string, and must be enclosed inside double-quotes C<">
-characters as per the JSON specification.
+Each filter is given as a name/value pair.
 Parameters to that filter are provided as the value part of the name/value pair,
 and will normally appear as a child JSON object consisting of name/value pairs
 inside a nested pair of braces C< {} >.
@@ -42,14 +42,18 @@ inside a nested pair of braces C< {} >.
 
 Given a record called C<test:channel> the following would apply a filter C<f> to
 the VAL field of that record, giving the filter two numeric parameters named
-C<lo> and C<hi>:
+C<lo> and C<hi> and a string parameter C<s>:
+
+ "test:channel.{f:{lo:0,hi:10,s:'X'}}"
 
- test:channel.{"f":{"lo":0,"hi":10}}
+Note that due to the required presence of quotes around string values, and
+the way Unix shells expand braces, it is recommended to enclose a filtered name
+within either double quotes C<< "..." >> or single quotes C<< '...' >>.
+When using double quotes around the filter, use single quotes around string
+parameters and vice versa.
 
-Note that due to the required presence of the double-quote characters in the
-JSON strings in the name string, it will usually be necessary to enclose a
-filtered name within single-quotes C<< ' ... ' >> when typing it as an
-argument to a Unix shell command.
+Thanks to the new JSON5 parser, member names like the filter names and parameter
+names do not require quotes any longer.
 
 =head2 Filter Reference
 
@@ -57,7 +61,7 @@ argument to a Unix shell command.
 
 registrar(tsInitialize)
 
-=head3 TimeStamp Filter C<"ts">
+=head3 TimeStamp Filter C<ts>
 
 This filter is used to set the timestamp of the value fetched through
 the channel to the time the value was fetched (or an update was sent),
@@ -71,16 +75,16 @@ None, use an empty pair of braces.
 
 =head4 Example
 
- Hal$ caget -a 'test:channel.{"ts":{}}'
- test:channel.{"ts":{}}   2012-08-28 22:10:31.192547 0 UDF INVALID
- Hal$ caget -a 'test:channel'
+ Hal$ caget -a "test:channel.{ts:{}}"
+ test:channel.{ts:{}}   2012-08-28 22:10:31.192547 0 UDF INVALID
+ Hal$ caget -a "test:channel"
  test:channel             <undefined> 0 UDF INVALID
 
 =cut
 
 registrar(dbndInitialize)
 
-=head3 Deadband Filter C<"dbnd">
+=head3 Deadband Filter C<dbnd>
 
 This filter implements a channel-specific monitor deadband, which is applied
 after any deadbands implemented by the record itself (it can only drop updates
@@ -93,21 +97,21 @@ percentage.
 
 =over
 
-=item Mode+Deadband C<"abs">/C<"rel"> (shorthand)
+=item Mode+Deadband C<abs>/C<rel> (shorthand)
 
 Mode and deadband can be specified in one definition (shorthand).
-The desired mode is given as parameter name (C<"abs"> or C<"rel">), with the
+The desired mode is given as parameter name (C<abs> or C<rel>), with the
 numeric size of the deadband (absolute value or numeric percentage) as value.
 
-=item Deadband C<"d">
+=item Deadband C<d>
 
 The size of the deadband to use.
 Relative deadband values are given as a numeric percentage, but without any
 trailing percent character.
 
-=item Mode C<"m"> (optional)
+=item Mode C<m> (optional)
 
-A string (enclosed in double-quotes C<">), which should contain either
+A string (enclosed in quotes), which should contain either
 C<abs> or C<rel>.
 The default mode is C<abs> if no mode parameter is included.
 
@@ -115,7 +119,7 @@ The default mode is C<abs> if no mode parameter is included.
 
 =head4 Example
 
- Hal$ camonitor 'test:channel'
+ Hal$ camonitor test:channel
  test:channel                    2012-09-01 22:10:19.600595 1 LOLO MAJOR
  test:channel                    2012-09-01 22:10:20.600661 2 LOLO MAJOR
  test:channel                    2012-09-01 22:10:21.600819 3 LOW MINOR
@@ -123,19 +127,19 @@ The default mode is C<abs> if no mode parameter is included.
  test:channel                    2012-09-01 22:10:23.601023 5  
  test:channel                    2012-09-01 22:10:24.601136 6 HIGH MINOR
  ^C
- Hal$ camonitor 'test:channel.{"dbnd":{"abs":1.5}}'
- test:channel.{"dbnd":{"d":1.5}} 2012-09-01 22:11:49.613341 1 LOLO MAJOR
- test:channel.{"dbnd":{"d":1.5}} 2012-09-01 22:11:51.613615 3 LOW MINOR
- test:channel.{"dbnd":{"d":1.5}} 2012-09-01 22:11:53.613804 5  
- test:channel.{"dbnd":{"d":1.5}} 2012-09-01 22:11:55.614074 7 HIGH MINOR
- test:channel.{"dbnd":{"d":1.5}} 2012-09-01 22:11:57.614305 9 HIHI MAJOR
+ Hal$ camonitor "test:channel.{dbnd:{abs:1.5}}"
+ test:channel.{dbnd:{d:1.5}} 2012-09-01 22:11:49.613341 1 LOLO MAJOR
+ test:channel.{dbnd:{d:1.5}} 2012-09-01 22:11:51.613615 3 LOW MINOR
+ test:channel.{dbnd:{d:1.5}} 2012-09-01 22:11:53.613804 5  
+ test:channel.{dbnd:{d:1.5}} 2012-09-01 22:11:55.614074 7 HIGH MINOR
+ test:channel.{dbnd:{d:1.5}} 2012-09-01 22:11:57.614305 9 HIHI MAJOR
  ^C
 
 =cut
 
 registrar(arrInitialize)
 
-=head3 Array Filter C<"arr">
+=head3 Array Filter C<arr>
 
 This filter is used to retrieve parts of an array (subarrays and strided
 subarrays).
@@ -153,16 +157,16 @@ Any parameter may be omitted (keeping the colons) to use the default value.
 If only one colon is included, this means C<[start:end]> with an increment of 1.
 If only a single parameter is used C<[index]> the filter returns one element.
 
-=item Start index C<"s">
+=item Start index C<s>
 
 Index of the first original array element to retrieve.
 
-=item Increment C<"i">
+=item Increment C<i>
 
 Index increment between retrieved elements of the original array; must be
 a positive number.
 
-=item End index C<"e">
+=item End index C<e>
 
 Index of the last original array element to retrieve.
 
@@ -174,9 +178,9 @@ C<s=0> (first element), C<i=1> (fetch all elements), C<e=-1>
 
 =head4 Example
 
- Hal$ caget test:channel 'test:channel.{"arr":{"s":2,"i":2,"e":8}}' test:channel.[3:5] test:channel.[3:2:-3]
+ Hal$ caget test:channel "test:channel.{arr:{s:2,i:2,e:8}}" test:channel.[3:5] test:channel.[3:2:-3]
  test:channel 10 0 1 2 3 4 5 6 7 8 9
- test:channel.{"arr":{"s":2,"i":2,"e":8}} 4 2 4 6 8
+ test:channel.{arr:{s:2,i:2,e:8}} 4 2 4 6 8
  test:channel.[3:5] 3 3 4 5
  test:channel.[3:2:-3] 3 3 5 7
 
@@ -184,7 +188,7 @@ C<s=0> (first element), C<i=1> (fetch all elements), C<e=-1>
 
 registrar(syncInitialize)
 
-=head3 Synchronize Filter C<"sync">
+=head3 Synchronize Filter C<sync>
 
 This filter is used to dynamically enable or disable monitors according
 to a condition and a state variable declared by the IOC.
@@ -200,57 +204,57 @@ C<dbStateSet()>.
 =item Mode+State
 
 Mode and state can be specified in one definition (shorthand).
-The desired mode is given as parameter name (C<"before"> / C<"first"> /
-C<"while"> / C<"last"> / C<"after"> / C<"unless">), with the state name
-(enclosed in double quotes C<">) as value.
+The desired mode is given as parameter name (C<before> / C<first> /
+C<while> / C<last> / C<after> / C<unless>), with the state name
+(enclosed in quotes) as value.
 
-=item Mode C<"m">
+=item Mode C<m>
 
-A single word from the list below, enclosed in double quotes C<">.
+A single word from the list below, enclosed in quotes.
 This controls how the state value should affect the monitor stream. 
 
 =over
 
-=item C<"before"> E<mdash> only the last value received before the state
+=item C<before> E<mdash> only the last value received before the state
 changes from false to true is forwarded to the client.
 
-=item C<"first"> E<mdash> only the first value received after the state
+=item C<first> E<mdash> only the first value received after the state
 changes from true to false is forwarded to the client.
 
-=item C<"while"> E<mdash> values are forwarded to the client as long as
+=item C<while> E<mdash> values are forwarded to the client as long as
 the state is true.
 
-=item C<"last"> E<mdash> only the last value received before the state
+=item C<last> E<mdash> only the last value received before the state
 changes from true to false is forwarded to the client.
 
-=item C<"after"> E<mdash> only the first value received after the state
+=item C<after> E<mdash> only the first value received after the state
 changes from true to false is forwarded to the client.
 
-=item C<"unless"> E<mdash> values are forwarded to the client as long
+=item C<unless> E<mdash> values are forwarded to the client as long
 as the state is false.
 
 =back
 
-=item State C<"s">
+=item State C<s>
 
-The name of a state variable, enclosed in double quotes C<">.
+The name of a state variable, enclosed in quotes.
 
 =back
 
 =head4 Example
 
-Assuming there is a system state called "blue", that is being controlled by
+Assuming there is a system state called C<blue>, that is being controlled by
 some other facility such as a timing system, updates could be restricted to
-periods only when "blue" is true by using
+periods only when C<blue> is true by using
 
- Hal$ camonitor 'test:channel' 'test:channel.{"sync":{"while":"blue"}}'
+ Hal$ camonitor test:channel "test:channel.{sync:{while:'blue'}}"
  ...
 
 =cut
 
 registrar(decInitialize)
 
-=head3 Decimation Filter C<"dec">
+=head3 Decimation Filter C<dec>
 
 This filter is used to reduce the number or rate of monitor updates from a
 channel by an integer factor C<n> that is provided as a filter argument,
@@ -262,7 +266,7 @@ update through.
 
 =over
 
-=item Number C<"n">
+=item Number C<n>
 
 The decimation factor, a positive integer. Giving n=1 is equivalent to a no-op
 that allows all updates to be passed to the client.
@@ -281,7 +285,56 @@ client connects.
 To sample a 60Hz channel at 1Hz, a 10Hz channel every 6 seconds or a 1Hz channel
 once every minute:
 
- Hal$ camonitor 'test:channel' 'test:channel.{"dec":{"n":60}}'
+ Hal$ camonitor test:channel "test:channel.{dec:{n:60}}"
  ...
 
 =cut
+
+registrar(infoInitialize)
+
+=head3 Info Field Filter C<info>
+
+This filter gives access to the info fields of a record.
+
+=head4 Parameters
+
+=over
+
+=item Name C<name> or C<n>
+
+The name of the info field.
+Currently, there is an implementation limit of 50 chars
+for the name length.
+
+=item Long String Flag C<longstr> or C<l>
+
+If this optional flag is C<'yes'>, C<'on'> or C<1>, the info field is
+returned as an array of C<CHAR>.
+If it is C<'no'>, C<'off'> or C<0>, the info field is returned as a
+C<STRING>, truncated to 40 characters if necessary.
+The default is C<'auto'>, which will use C<STRING> for sufficiently short values
+and array of C<CHAR> for long values.
+
+Alternatively, long strings can be requested by adding a C<$> to the filter
+name or the name parameter.
+
+=back
+
+=head4 Example
+
+Assuming the record C<test:channel> has:
+
+ info(infofieldname, "value of the info field")
+
+To read the value of the info field:
+
+ $ caget "test:channel.{info:{name:'infofieldname'}}"
+ test:channel.{info:{name:'infofieldname'}} value of the info field
+ $ caget -S "test:channel.{info:{name:'infofieldname',l:'yes'}}"
+ test:channel.{info:{name:'infofieldname'}} value of the info field
+ $ caget -S "test:channel.{info$:{name:'infofieldname'}}"
+ test:channel.{info$:{name:'infofieldname'}} value of the info field
+ $ caget -S "test:channel.{info:{n$:'infofieldname'}}"
+ test:channel.{info:{n$:'infofieldname'}} value of the info field
+
+=cut
diff --git a/modules/database/src/std/filters/info.c b/modules/database/src/std/filters/info.c
new file mode 100644
index 0000000..b14d7ed
--- /dev/null
+++ b/modules/database/src/std/filters/info.c
@@ -0,0 +1,189 @@
+/*************************************************************************\
+* Copyright (c) 2021 Paul Scherrer Institute
+* SPDX-License-Identifier: EPICS
+* EPICS BASE is distributed subject to a Software License Agreement found
+* in file LICENSE that is included with this distribution.
+\*************************************************************************/
+
+/*
+ *  Author: Dirk Zimoch <[e-mail]>
+ */
+
+#include <stdio.h>
+#include <string.h>
+
+#include "chfPlugin.h"
+#include "dbStaticLib.h"
+#include "dbAccessDefs.h"
+#include "epicsExit.h"
+#include "freeList.h"
+#include "epicsExport.h"
+
+typedef struct myStruct {
+    char name[52];  /* arbitrary size, we better had dynamic strings */
+    DBENTRY dbentry;
+    int longstr;
+} myStruct;
+
+static void *myStructFreeList;
+
+static const
+chfPluginEnumType longstrEnum[] = {{"no",0}, {"off",0}, {"yes",1}, {"on",1}, {"auto",2}, {NULL, 0}};
+
+static const chfPluginArgDef opts[] = {
+/*                          member,   name,   [tagmember, tagval,] required, convert, [enums] */
+    chfString    (myStruct, name,    "name",                         1,         0),
+    chfString    (myStruct, name,    "n",                            1,         0),
+    chfTagString (myStruct, name,    "name$",   longstr,     1,      1,         0),
+    chfTagString (myStruct, name,    "n$",      longstr,     1,      1,         0),
+    chfTagString (myStruct, name,    "$",       longstr,     1,      1,         0),
+    chfEnum      (myStruct, longstr, "longstr",                      0,         1,   longstrEnum),
+    chfEnum      (myStruct, longstr, "l",                            0,         1,   longstrEnum),
+    chfPluginArgEnd
+};
+
+static void * allocPvt(void)
+{
+    myStruct *my = (myStruct*) freeListCalloc(myStructFreeList);
+    if (!my) return NULL;
+    my->longstr = 2;
+    return (void *) my;
+}
+
+static void freePvt(void *pvt)
+{
+    freeListFree(myStructFreeList, pvt);
+}
+
+static int parse_ok(void *pvt)
+{
+    myStruct *my = (myStruct*) pvt;
+    if (my->name[0] == 0) /* empty name */
+        return -1;
+    if (my->name[sizeof(my->name)-2] != 0) /* name buffer overrun */
+        return -1;
+    return 0;
+}
+
+static int parse_ok_long(void *pvt)
+{
+    myStruct *my = (myStruct*) pvt;
+    my->longstr = 1;
+    return parse_ok(pvt);
+}
+
+static void dbfl_free(struct db_field_log *pfl)
+{
+    /* dummy needed for dbGet() to work correctly */
+}
+
+static db_field_log* filter(void* pvt, dbChannel *chan, db_field_log *pfl)
+{
+    myStruct *my = (myStruct*) pvt;
+
+    if (pfl->type == dbfl_type_ref && pfl->u.r.dtor)
+        pfl->u.r.dtor(pfl);
+    pfl->type = dbfl_type_ref;
+    pfl->u.r.dtor = dbfl_free;
+    pfl->u.r.field = (void*)dbGetInfoString(&my->dbentry);
+
+    if (my->longstr) {
+        pfl->field_size = 1;
+        pfl->field_type = DBF_CHAR;
+        pfl->no_elements = strlen((char*)pfl->u.r.field)+1;
+    } else {
+        pfl->field_size = MAX_STRING_SIZE;
+        pfl->field_type = DBF_STRING;
+        pfl->no_elements = 1;
+    }
+    return pfl;
+}
+
+static long channel_open(dbChannel *chan, void *pvt)
+{
+    myStruct *my = (myStruct*) pvt;
+    DBENTRY* pdbe = &my->dbentry;
+    int status;
+
+    dbInitEntryFromAddr(&chan->addr, pdbe);
+    for (status = dbFirstInfo(pdbe); !status; status = dbNextInfo(pdbe))
+        if (strcmp(dbGetInfoName(pdbe), my->name) == 0)
+            return 0;
+    return -1;
+}
+
+static void channelRegisterPre(dbChannel *chan, void *pvt,
+    chPostEventFunc **cb_out, void **arg_out, db_field_log *pfl)
+{
+    myStruct *my = (myStruct*) pvt;
+    size_t len = strlen(dbGetInfoString(&my->dbentry)) + 1;
+    if (my->longstr == 2) {
+        my->longstr = len > MAX_STRING_SIZE;
+    }
+    if (my->longstr) {
+        pfl->field_size = 1;
+        pfl->field_type = DBF_CHAR;
+        pfl->no_elements = len;
+    } else {
+        pfl->field_size = MAX_STRING_SIZE;
+        pfl->field_type = DBF_STRING;
+        pfl->no_elements = 1;
+    }
+    *cb_out = filter;
+    *arg_out = pvt;
+}
+
+static void channel_report(dbChannel *chan, void *pvt, int level,
+    const unsigned short indent)
+{
+    myStruct *my = (myStruct*) pvt;
+    printf("%*sInfo: name=%s\n", indent, "",
+           my->name);
+}
+
+static chfPluginIf pif = {
+    allocPvt,
+    freePvt,
+
+    NULL, /* parse_error, */
+    parse_ok,
+
+    channel_open,
+    channelRegisterPre,
+    NULL, /* channelRegisterPost, */
+    channel_report,
+    NULL /* channel_close */
+};
+
+static chfPluginIf piflong = {
+    allocPvt,
+    freePvt,
+
+    NULL, /* parse_error */
+    parse_ok_long,
+
+    channel_open,
+    channelRegisterPre,
+    NULL, /* channelRegisterPost, */
+    channel_report,
+    NULL /* channel_close */
+};
+
+static void infoShutdown(void* ignore)
+{
+    if(myStructFreeList)
+        freeListCleanup(myStructFreeList);
+    myStructFreeList = NULL;
+}
+
+static void infoInitialize(void)
+{
+    if (!myStructFreeList)
+        freeListInitPvt(&myStructFreeList, sizeof(myStruct), 64);
+
+    chfPluginRegister("info", &pif, opts);
+    chfPluginRegister("info$", &piflong, opts);
+    epicsAtExit(infoShutdown, NULL);
+}
+
+epicsExportRegistrar(infoInitialize);
diff --git a/modules/database/test/std/filters/Makefile b/modules/database/test/std/filters/Makefile
index 2576ce4..190f406 100644
--- a/modules/database/test/std/filters/Makefile
+++ b/modules/database/test/std/filters/Makefile
@@ -65,6 +65,13 @@ decTest_SRCS += filterTest_registerRecordDeviceDriver.cpp
 testHarness_SRCS += decTest.c
 TESTS += decTest
 
+TESTPROD_HOST += infoTest
+infoTest_SRCS += infoTest.cpp
+infoTest_SRCS += filterTest_registerRecordDeviceDriver.cpp
+testHarness_SRCS += infoTest.cpp
+TESTFILES += ../infoTest.db
+TESTS += infoTest
+
 # epicsRunFilterTests runs all the test programs in a known working order.
 testHarness_SRCS += epicsRunFilterTests.c
 
diff --git a/modules/database/test/std/filters/epicsRunFilterTests.c b/modules/database/test/std/filters/epicsRunFilterTests.c
index 2b92b53..19952c1 100644
--- a/modules/database/test/std/filters/epicsRunFilterTests.c
+++ b/modules/database/test/std/filters/epicsRunFilterTests.c
@@ -19,6 +19,7 @@ int dbndTest(void);
 int syncTest(void);
 int arrTest(void);
 int decTest(void);
+int infoTest(void);
 
 void epicsRunFilterTests(void)
 {
@@ -29,6 +30,7 @@ void epicsRunFilterTests(void)
     runTest(syncTest);
     runTest(arrTest);
     runTest(decTest);
+    runTest(infoTest);
 
     dbmfFreeChunks();
 
diff --git a/modules/database/test/std/filters/infoTest.cpp b/modules/database/test/std/filters/infoTest.cpp
new file mode 100644
index 0000000..070d23d
--- /dev/null
+++ b/modules/database/test/std/filters/infoTest.cpp
@@ -0,0 +1,132 @@
+/*************************************************************************\
+* Copyright (c) 2021 European Spallation Source (ERIC)
+* SPDX-License-Identifier: EPICS
+* EPICS BASE is distributed subject to the Software License Agreement
+* found in the file LICENSE that is included with this distribution.
+\*************************************************************************/
+
+/*
+ *  Author: Simon Rose <[e-mail]>
+ */
+
+#include <string.h>
+
+#include "epicsStdio.h"
+#include "dbStaticLib.h"
+#include "errlog.h"
+#include "dbAccess.h"
+#include "dbChannel.h"
+#include "dbUnitTest.h"
+#include "testMain.h"
+
+extern "C" {
+    void filterTest_registerRecordDeviceDriver(struct dbBase *);
+}
+
+#define DEBUG(fmt, x) printf("DEBUG (%d): %s: " fmt "\n", __LINE__, #x, x)
+
+static void runSingleTest(const char *json, dbfType dbf_type, const char *type, const char *expected) {
+    dbChannel *pch;
+    db_field_log fl;
+    db_field_log *pfl;
+    DBADDR addr;
+    char data[80];
+    long nreq;
+    char name[80] = "x.";
+
+    strncat(name, json, sizeof(name)-strlen(name)-1);
+
+    testOk(!!(pch = dbChannelCreate(name)), "dbChannel with plugin %s successful", name);
+    testOk((ellCount(&pch->filters) == 1), "Channel has one plugin");
+
+    testOk(!(dbChannelOpen(pch)), "dbChannel with plugin info opened");
+    testOk(pch->final_type == dbf_type, "Channel type should be %s", type);
+
+    memset(&fl, 0, sizeof(fl));
+    pfl = dbChannelRunPreChain(pch, &fl);
+    testOk(pfl->field_type == dbf_type, "Field type should be %s", type);
+
+    dbNameToAddr(name, &addr);
+    dbScanLock(addr.precord);
+    nreq = strlen(expected) + 1;
+    dbGet(&addr, dbf_type, &data, NULL, &nreq, pfl);
+    dbScanUnlock(addr.precord);
+
+    testOk(strcmp(expected, data) == 0, "Info string matches expected '%s'", expected);
+
+    dbChannelDelete(pch);
+}
+
+MAIN(arrTest)
+{
+    dbChannel *pch;
+    const chFilterPlugin *plug;
+    char info[] = "info";
+    dbEventCtx evtctx;
+    DBENTRY dbentry;
+    const char test_info_str[] = "xxxxxxxxxxxx";
+    const char test_info_str_long[] = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
+    const char test_info_str_truncated[] = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
+
+    testPlan(30);
+
+    /* Prepare the IOC */
+
+    testdbPrepare();
+
+    testdbReadDatabase("filterTest.dbd", NULL, NULL);
+
+    filterTest_registerRecordDeviceDriver(pdbbase);
+
+    testdbReadDatabase("xRecord.db", NULL, NULL);
+
+    eltc(0);
+    testIocInitOk();
+    eltc(1);
+
+    /* Start the IOC */
+
+    evtctx = db_init_events();
+
+    testOk(!!(plug = dbFindFilter(info, strlen(info))), "plugin 'info' registered correctly");
+
+
+    testDiag("Testing failing info tag reads");
+    testOk(!dbChannelCreate("x.{info:{}}"), "dbChannel with plugin {info:{}} failed");
+    testOk(!dbChannelCreate("x.{info:{name:\"\"}}"), "dbChannel with plugin {info:{name:\"\"}} failed");
+    testOk(!dbChannelCreate("x.{info:{name:\"0123456789a123456789b123456789c123456789d123456789e\"}}"), "dbChannel with plugin {info:{name:\"<too long name>\"}} failed");
+
+
+    testDiag("Testing non-existent tags");
+    testOk(!!(pch = dbChannelCreate("x.{info:{name:\"non-existent\"}}")), "dbChannel with plugin {info:{name:\"non-existent\"}} created");
+    testOk(!!(dbChannelOpen(pch)), "dbChannel with non-existent info tag did not open");
+
+    /*
+     * Update the record to add the correct info record
+     */
+    dbInitEntry(pdbbase, &dbentry);
+    dbFindRecord(&dbentry,"x");
+    dbPutInfo(&dbentry, "a", test_info_str);
+    dbPutInfo(&dbentry, "b", test_info_str_long);
+
+
+    testDiag("Testing valid info tag");
+    runSingleTest("{info:{name:\"a\"}}", DBF_STRING, "DBF_STRING", test_info_str);
+
+    testDiag("Testing long string");
+    runSingleTest("{info:{name:\"a\", l:\"on\"}}", DBF_CHAR, "DBF_CHAR", test_info_str);
+
+    testDiag("Testing long string, full");
+    runSingleTest("{info:{name:\"b\", l:\"auto\"}}", DBF_CHAR, "DBF_CHAR", test_info_str_long);
+
+    testDiag("Testing long string, truncated");
+    runSingleTest("{info:{name:\"b\", l:\"off\"}}", DBF_STRING, "DBF_STRING", test_info_str_truncated);
+
+    db_close_events(evtctx);
+
+    testIocShutdownOk();
+
+    testdbCleanup();
+
+    return testDone();
+}