Convert NDPluginPva to use PVXS

[coretl]

In epics-containers/epics-base we are building EPICS base with PVXS rather than pvAccess. This solves a number of issues for us, including the addition of PVA_NAME_SERVERS which means we can use TCP only allowing use of the network address translation needed in Kubernetes without exposing host network. (@gilesknap please correct me if I have got this wrong)

The only remaining component for us that is using the old pvAccess stack is the NDPluginPVA.

Would it be possible to convert it to use PVXS? Should it be an in place conversion, or should there be a Makefile switch to build an NDPluginPva against pvAccess or PVXS?

I noticed that #485 was commented as a stepping stone to PVXS by @mdavidsaver but is still marked as draft.

DLS is happy to do this work, but would need some guidance on the best approach, and someone to review the PR!

[MarkRivers]

I am happy to defer to Michael and DLS experts on this. It would be simplest to just convert to PVXS I think, I think we also need to change pvaDriver, which shares some of the code.

[mp49]

If we can add PVXS support via compile time flags, that would be best at the moment. I suspect quite a few sites are using NDPluginPVA via the older PVAccess support bundled with base 7.0.X.

[coretl]

@Ohisemega please could you start looking at this? Once you've scanned through the PVXS docs there will probably be some questions for @mdavidsaver but we can get started before arranging a meeting to answer those questions

[jsouter]

Took a little bit to get my environment set up but making progress with this, most of my questions were indirectly answered on friday, will open a wip draft PR when I get things tidied up.

[gilesknap]

Took a little bit to get my environment set up but making progress with this, most of my questions were indirectly answered on friday, will open a wip draft PR when I get things tidied up.

@jsouter FYI you could have:

• clone git@github.com:epics-containers/ioc-adsimdetector.git
• open in devcontainer with vscode
• ansible.sh pvxs # this installs the support which I don't have by default in Areadetector generic IOCs
• cd /epics/support/ADCore; make

This also gives you a test instance to try things against. Let me know if you want a quick 10 minute demo.

[jsouter]

Took a little bit to get my environment set up but making progress with this, most of my questions were indirectly answered on friday, will open a wip draft PR when I get things tidied up.

@jsouter FYI you could have:

• clone git@github.com:epics-containers/ioc-adsimdetector.git
• open in devcontainer with vscode
• ansible.sh pvxs # this installs the support which I don't have by default in Areadetector generic IOCs
• cd /epics/support/ADCore; make

This also gives you a test instance to try things against. Let me know if you want a quick 10 minute demo.

Thanks Giles, I had a quick go last week trying to set up something in this container, ultimately I'm using ADSimDetector outside of a container so I can just use xmlbuilder a bit easier, maybe a quick demo would be good if you have some time tomorrow.

[gilesknap]

@jsouter I'm on leave this week. Please drop something in my diary for next week. The devcontainer can also let you quickly make IOC instances too so no xmlbuilder needed.

[jsouter]

Still tidying up but very close to replicating the full functionality of the pvAccess version, I'm a bit stuck on reimplementing toAttribute/toAttributes - I'm not sure how to identify the specialised type of an Any field. @mdavidsaver can you advise? Reading the type code of the NTNDArray Value attributes' "value" field just returns Any, I'm sure the specialisation information must exist somewhere as the PVXS struct does show the specific type, e.g. long on a pvget, but I'm not sure how to get it through the pvxs::Value api.

[mdavidsaver]

type code of the NTNDArray Value attributes' "value" field just returns Any

The Any is a container. An indirection is needed get access the contents.

Value avalue(top["some.value"]); // traverse to an Any field
assert(avalue.type()==TypeCode::Any);
Value contents(avalue.as<Value>()); // extract Value pointed to by Any (may be nothing).

This can also be expressed as:

Value contents(top["some.value->"]); // indirect during traverse

[jsouter]

type code of the NTNDArray Value attributes' "value" field just returns Any

The Any is a container. An indirection is needed get access the contents.

Value avalue(top["some.value"]); // traverse to an Any field
assert(avalue.type()==TypeCode::Any);
Value contents(avalue.as()); // extract Value pointed to by Any (may be nothing).
This can also be expressed as:

Value contents(top["some.value->"]); // indirect during traverse

Thanks! That did the trick.

[jsouter]

Draft is up here,
I believe it is mostly functionally the same as the pvAccess implementation, barring a few TODOs. It would probably be a good idea to update pvaDriver in a similar way though it is not strictly required, in my testing I am using the PVXS version of the converter but the pvAccess version of all the monitor logic for ease of testing.
#532

[coretl]

@jsouter please could you talk to @gilesknap about getting the epics-containers demo updated and seeing if it solves the NAT issues please?