|
|
Experimental Physics and
| ||||||||||||||
|
|
Hi Dave,
Over Channel Access I believe it’s possible for a record to belong to an Access Security Group that has READ access disabled for some or all users. However this is (almost?) never used and could confuse and/or crash many if not all CA client programs when accessing
those PVs since the record’s fields can still be connected to (they aren’t actually hidden from clients), but they won’t return any data or metadata.
If you could make some records only visible to a subset of users there is a danger that multiple records could exist with the same name, but a conflict would only be visible to users who can see both definitions. How should the client code decide which server
to connect to in that case?
I believe the PVA existing servers have no support for disabling READ access that way, so any client can read and subscribe to any PV. That may not be the case for servers running the Secure PVA protocol though, the group working on them may have built record
hiding into that. Someone else would have to answer that question though, and explain how they propose to resolve the above issue if they do support record hiding.
EPICS’s use of a flat name-space is why developing and enforcing a hierarchical naming convention is very important when designing EPICS-based control systems. I recommend searching for previous tech-talk discussions about that topic, or asking specifically
about that (almost every large site should have done that).
At the APS one of our conventions is that record names ending in an underscore character “_” are intended to be private to the IOC implementation (as is common in Python I believe). By not actually hiding those PVs they remain accessible for debugging; they
can be configured to be read-only, or only writable by the IOC developer(s).
HTH,
- Andrew
-- Complexity comes for free, Simplicity you have to work for.
| ||||||||||||||
| ANJ, 19 Mar 2026 |
·
Home
·
News
·
About
·
Talk
·
Base
·
Modules
·
Extensions
·
· Distributions · Download · Documents · Links · Licensing · |