GEM_AMC.GEM_SYSTEM.RELEASE is not readable but used in HwGenericAMC

[mexanick]

Brief summary of issue

Apr  1 20:48:19 CTP7 user.info rpcsvc: eagle48[26477] - void utils::initLogging() - Impossible to read the configuration file; using the default embedded configuration.
Apr  1 20:48:19 CTP7 user.info rpcsvc: eagle48[26477] - int memhub_open(memsvc_handle**) - Memhub initialized a semaphore. Current semaphore value = 1
Apr  1 20:48:19 CTP7 user.info rpcsvc: eagle48[26477] - void utils::initLogging() - Impossible to read the configuration file; using the default embedded configuration.
Apr  1 20:48:19 CTP7 user.err rpcsvc: eagle48[26477] - uint32_t utils::readReg(const string&) - No read permissions for GEM_AMC.GEM_SYSTEM.RELEASE:

Indeed, an attempt of read("GEM_AMC.GEM_SYSTEM.RELEASE") is happening in the gem::hw::amc::HwGenericAMC::getFirmwareVer() and this register doesn't have any permissions in the address table. @evka please comment what's the desired behavior here and how to fix (change the register, update address table)

Types of issue

• Bug report (report an issue with the code)
• Feature request (request for change which adds functionality)

Your Environment

• Version used: test PR Hw access optimization #327
• Shell used:

[lpetre-ulb]

I'm not convinced we want to be able to access non-leaf registers. If it was possible, it would mean making assumptions on how the sub-registers are organized. In this specific case, the masks to access the sub-registers.

If we are moving towards the "giant struct" address table, this kind non-leaf register access could be coalesced in a safe manner which would not depend on the underlying implementation details.

[jsturdy]

This is a longstanding bug or lack/divergence of functionality with the non-uhal address table parsing (which had perfectly clear semantics for this use case, via default attributes).
The same semantics were discussed/requested in the past, but never implemented in the non-uhal address table parsing, and so certain simple features were only compatible with the uhal devices.
I don't know if the issue is in generating the FW from the xml (also, ipbus guys did this with their semantics without problems it seems), or with the parser as currently designed.

All that to say, this issue is better suited for https://github.com/cms-gem-daq-project/reg_utils or https://github.com/cms-gem-daq-project/xhal or https://github.com/cms-gem-daq-project/GEM_AMC probably, because it really has nothing to do with what's happening here, unless you're simply rewriting the getFirmwareVer() function to work with the constraints of the non-uhal system

[mexanick]

There's actually a lot more to this. Moreover, I consider the reading of non-leaf nodes dangerous as reshuffling the masked registers or changing their meaning under the parent node may lead to undefined behavior and can not be easily checked at run time.