cmsgemos issueshttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues2022-06-15T14:06:54+02:00https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/184On the data formats...2022-06-15T14:06:54+02:00Laurent PetreOn the data formats...### Summary
There were a few informal discussions and ideas thrown about the file formats to use in the longer term. Let's try to formalize it better.
* `XML` to be minimized as much as possible:
* _Libraries_: `xdata`, `xoap`, and `...### Summary
There were a few informal discussions and ideas thrown about the file formats to use in the longer term. Let's try to formalize it better.
* `XML` to be minimized as much as possible:
* _Libraries_: `xdata`, `xoap`, and `xerces`
* SOAP calls to be replaced with a JSON API when possible:
* Better unification with the Web interface and reduction of the code duplication
* xDAQ static configuration to be kept to its minimum
* `YAML` for the configuration files:
* _Library_: `yaml-cpp`
* Hardware layout tree
* Text configuration database
* Possibly application configuration
* `JSON` for information exchange:
* _Libraries_: `nlohmann/json` and `cereal`
* Web interface
* Import-export of configuration parameters
* Export of the monitorables
* ...
* `cereal` binary format for the RPC calls:
* _Library_: `cereal`
* Can it be replaced with `JSON`?
* Anyway, no duplication of code since the same library would be used for `JSON`
Then, the data-taking file formats:
* `GEM DAQ` data format within the CMS Raw file format:
* See #50 for more details
* Implementation in progress in !145
* Compressed `numpy` arrays for the non-tracking data scans:
* _Library_: To be developed
* Currently `CSV`-like, but storage hungry
* Could a simple compression of the CSV files be enough?https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/169How to store the non-tracking data scans and/or the local readout data?2021-03-24T13:17:44+01:00Laurent PetreHow to store the non-tracking data scans and/or the local readout data?### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
At the moment, there is no facility to store the output from the different xDAQ applications. This is starting to be an issue with ...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
At the moment, there is no facility to store the output from the different xDAQ applications. This is starting to be an issue with the implementation of the non-tracking data scans. It will be even more the case with the implementation of the local readout.
A notable specificity is that the output files will be split following the xDAQ applications (i.e. one application per back-end board). This could be prevented with a centralized application gathering the data from all applications.
The first possibility that comes to my mind is to create a directory per xDAQ application per run (request the run the the `RunInfo` database like the CSC?). Any function could drop its files in the previously mentioned directory.
### What is the expected correct behavior?
<!--- What you should see instead -->
Where and how to store the information is clearly defined. A generic implementation is provided.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/152About the rendering of monitorables2021-02-10T11:49:01+01:00Laurent PetreAbout the rendering of monitorables### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
As discussed in https://gitlab.cern.ch/cmsgemonline/cmsgemos/-/merge_requests/92#note_4130335 and in https://gitlab.cern.ch/cmsgemo...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
As discussed in https://gitlab.cern.ch/cmsgemonline/cmsgemos/-/merge_requests/92#note_4130335 and in https://gitlab.cern.ch/cmsgemonline/cmsgemos/-/merge_requests/66#note_4126411, the rendering of the monitorables should be different depending on the state of the hardware and the data-taking status.
A few points seem to emerge from the linked discussions:
1. Only the pieces of hardware that actually exist (as per the hardware layout tree) should be displayed.
2. Disabled pieces of hardware (either manually in the configuration or automatically masked) should be rendered differently (grayed?)
3. The color style should depend on the data-taking conditions (e.g. non-locking GBT in the "Initialized" step are not critical while they are during data-taking).
The exact communication protocol between the different applications is still to be defined.
### What is the expected correct behavior?
<!--- What you should see instead -->
The rendering style is clear for the user and adapted to the hardware and to the different data-taking conditions.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/128New web interface for xDAQ applications2024-01-17T11:59:12+01:00Laurent PetreNew web interface for xDAQ applications### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
At the moment, `xgi`/`cgi` is being used to create the web interface of the xDAQ applications. This is an old methodology and hard ...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
At the moment, `xgi`/`cgi` is being used to create the web interface of the xDAQ applications. This is an old methodology and hard to use and maintain. We can certainly do better with new web frameworks and a JSON API.
### What is the expected correct behavior?
<!--- What you should see instead -->
* The xDAQ applications only provide a JSON API;
* The web interface is created with a modern web framework such as Vue.js.Dylan Oliver TeagueDylan Oliver Teaguehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/121Configuration database schema2022-03-18T23:34:16+01:00Louis MoureauxConfiguration database schema### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
Since we're going for a RDBMS, we'll need to develop a schema for the configuration database. (RDBMS are much stricter when it come...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
Since we're going for a RDBMS, we'll need to develop a schema for the configuration database. (RDBMS are much stricter when it comes to the data contents.) Proposals can be discussed here.
### Relevant logs and/or screenshots
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
[This presentation](https://indico.cern.ch/event/842045/#290-db-needs-from-a-daq-and-b) may be useful.Avijit ChakrabortySree BhattacharyyaAvijit Chakrabortyhttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/87Large data transfers in RPC calls2020-05-18T10:52:28+02:00Laurent PetreLarge data transfers in RPC calls### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
[Migrated from [this GitHub issue](https://github.com/cms-gem-daq-project/ctp7_modules/issues/168).]
> I agree that the message si...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
[Migrated from [this GitHub issue](https://github.com/cms-gem-daq-project/ctp7_modules/issues/168).]
> I agree that the message size should not matter to the user and should be, if required, fragmented in the lower layers.
>
> However, this is not how the rpcsvc framework/service is designed; the messages must be kept relatively small, under 8 MiB. You could probably work around it in the templated RPC framework; it would probably be easier and faster to re-write the rpcsvc daemon. Also, the RPC calls are not designed as a streaming service, so that the whole message must be buffered at some point... but the memory is limited in the CTP7.
_[From @lpetre](https://github.com/cms-gem-daq-project/ctp7_modules/pull/167#discussion_r373881987)._
> Neither the `rpcsvc` service nor the template RPC frameworks were designed for large data transfers. They require the whole dataset to be available before sending it.
>
> An option to implement this feature would be to open a `socket`, allowing the two ends of a call to communicate asynchronously while the call is running. This could be achieved by constructing a special data type whose serialization and deserialization hooks would handle the `socket`. It would be passed as function arguments. It would not be trivial to implement and use.
>
> The size of the configuration is driven by VFAT data. Each channel is 2 bytes, plus 18x4 bytes for control registers. Therefore an AMC configuration is O(100kB).
_[From @lmoureau](https://github.com/cms-gem-daq-project/ctp7_modules/issues/168#issuecomment-581447012)._
### What is the expected correct behavior?
<!--- What you should see instead -->
Decide whether the feature is needed and desired. Design and implement a solution it if the answer to both these questions is "yes".
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/86Use sementically correct types2020-05-18T10:29:07+02:00Laurent PetreUse sementically correct types### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
Currently, the variable types are good enough to get the code working, but not always "the best ones" in term of ...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
Currently, the variable types are good enough to get the code working, but not always "the best ones" in term of semantics. This can be improved while going through the refactoring.
[Migrated from [this GitHub issue](https://github.com/cms-gem-daq-project/ctp7_modules/issues/108) which started with [that comment](https://github.com/cms-gem-daq-project/ctp7_modules/pull/107#discussion_r269985743).]
### What is the expected correct behavior?
<!--- What you should see instead -->
Variable types are chosen according to the variable semantic.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
<!--- ### Possible fixes -->
<!--- If you can, provide a code snippet which may implement the requested feature -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/85Design SCA tool for monitoring/future2020-05-21T12:34:57+02:00Dylan Oliver TeagueDesign SCA tool for monitoring/future### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
As has started as a discussion in #12, SCA monitoring has been moved into functions in [this file](https://gitlab.cern.ch/cmsgemonli...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
As has started as a discussion in #12, SCA monitoring has been moved into functions in [this file](https://gitlab.cern.ch/cmsgemonline/cmsgemos/-/blob/develop/gemrpc/src/amc/sca.cpp), and thankfully, a lot of functionality is available in the form of getter functions:
- readSCAADCTemperatureSensors
- readSCAADCVoltageSensors
- readSCAADCSignalStrengthSensors
- readAllSCAADCSensors
Since these variables are one we would be interested in using the monitoring suite, it makes sense to review this to make sure it meets all our the requirements we have for the monitoring code.
1. Compatible with GE2/1. Talking with @evka, this is as easy as replacing the GE1/1 enums that specify the channels with GE2/1 enums, but this is currently not implemented in the code.
2. Possibly centralizing naming scheme of SCA channels: currently [in the channel enums](https://gitlab.cern.ch/cmsgemonline/cmsgemos/-/blob/develop/gemrpc/interface/amc/sca_enums.h#L175), there are many aliased channels which were added (I think) to stay compatible with old RPC register names (eg, FPGA_CORE and INT_V1P0 are same channel, but different register calls in the old code), but this could be cleaned up to avoid confusion of channel naming
3. Make the return types of the read functions a `map<std::string, uint32_t>` instead of the current `vector<uint32_t>` form. All current calls in `daq_monitor.cpp` return as a map making it easy to use the data, but as a vector, the ordering matters heavily which could be problematic for any code change. I'm not sure if the vector version is absolutely needed. If so, the "map" version could possibly be written for the `daq_monitor.cpp` file alone.
It would behoove us to make special attention to this in documentation as well. The way the SCA data is retrieved is by selecting a channel and a `DATA` register is filled with the channel data. Because of these extra steps, getting this information is not as easy as accessing a simple register and should be drawn notice in the documentation somewhere.
There are probably more points to consider, but these were things I was thinking (with @lpetre thanks!), and could be expandedhttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/81Impact of CFG_CAL_DUR for voltage step calibration pulses2020-05-19T08:34:34+02:00Laurent PetreImpact of CFG_CAL_DUR for voltage step calibration pulses### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
As explained in [@evka's slides (non presented during last meeting)](https://indico.cern.ch/event/918874/contributions/3861717/atta...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
As explained in [@evka's slides (non presented during last meeting)](https://indico.cern.ch/event/918874/contributions/3861717/attachments/2038021/3412751/2020-05-13_EJ_GEM_DAQ.pdf), the `CFG_CAL_DUR` VFAT3 parameter has significant impacts on the calibration pulses, even in voltage step pulses mode.
No mention of this behavior is described in the VFAT3 (`CFG_CAL_DUR` is only mentioned for current calibration pulses). Thus the register was set to a arbitrary value. VFAT3 designers will be contacted to understand that parameter meaning.
Might explain #70.
### What is the expected correct behavior?
<!--- What you should see instead -->
One would know how to set the `CFG_CAL_DUR` VFAT3 register correctly for voltage step calibration pulses.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/78Make monitoring RPC methods resistant to single monitorable transaction errors2020-05-11T13:25:11+02:00Laurent PetreMake monitoring RPC methods resistant to single monitorable transaction errors### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
In their current state, the monitoring RPC methods either return the values from all the registers they are supposed to read, or fr...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
In their current state, the monitoring RPC methods either return the values from all the registers they are supposed to read, or from none of the registers.
Indeed, since the tempated RPC migration, `utils::readReg` can now throw an exception which is not caught into the monitoring RPC methods. As a consequence, the exception is forwarded to the client code, which catches the exception, but does not retrieve the actual monitorable values.
Different options can be envisioned, among them:
1. Each register access is protected in a `try-catch` block.
2. An alternate version of `utils::readReg` exist to make a read attempt.
In any case, a way to return the failed reads to the caller must designed. Return `0xdeaddead` is _not_ a long term solution since that value as valid as any other. A possibility would be not to filled the returned map with a key corresponding to the failed transaction. The client code will have to be adapted to be able to cope with such cases.
### What is the expected correct behavior?
<!--- What you should see instead -->
A failing register read (or write) should not fail the whole monitoring "block".
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/68Online DB design discussion2023-05-07T04:27:07+02:00Camilla GalloniOnline DB design discussion### Summary
This issue targets the start of the discussion for the fimalization of the desing of the Online DB.
It would be nice to outline the pros and cons of different choices of the back end system (git, MongoDBe etc ..),
and the ma...### Summary
This issue targets the start of the discussion for the fimalization of the desing of the Online DB.
It would be nice to outline the pros and cons of different choices of the back end system (git, MongoDBe etc ..),
and the main use cases for the API implementation. To extend the discussion, a set of slides in one of the upcoming meetings may be presented.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/67Naming convention choice2020-06-10T23:28:49+02:00Laurent PetreNaming convention choice### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
We chose the WebKit style as the formatting style for the C++ code within this repository. That decision has been...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
We chose the WebKit style as the formatting style for the C++ code within this repository. That decision has been applied and enforced through the use of `clang-format`. Nevertheless, despite WebKit defining a complete coding style, the question was asked specifically about the formatting style and not the overall style. Therefore, the naming convention was not part of the question.
Currently, the naming convention for the variables, functions and classes is not well defined, and as a consequence not followed. This is particularly true for the names containing acronyms (so frequent in GEMs...) Whichever naming convention is chosen, a simple and explicit rule about the acronyms shall be devised.
Two of the main conventions which could be followed:
* Fully embrace the WebKit style and follow its naming convention (:mountain:)
* Follow the C++ standard library naming scheme, i.e. snake case (:beach:)
In any case, review and changes will be required.
**Please, use the reactions smileys to vote.** Feel free to add new proposals if desired.
### What is the expected correct behavior?
<!--- What you should see instead -->
The naming convention is well defined, **followed** and enforced.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
<!--- ### Possible fixes -->
<!--- If you can, provide a code snippet which may implement the requested feature -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/55Encourage using sanitizers2020-05-02T00:20:19+02:00Louis MoureauxEncourage using sanitizers### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
GCC and clang come with a set of sanitizers that attempt to find various common mistakes at runtime. Examples include out-of-bounds...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
GCC and clang come with a set of sanitizers that attempt to find various common mistakes at runtime. Examples include out-of-bounds array indices, dangling pointers, unsafe concurrent access, division by zero... They are enabled using the `-fsanitize` compiler option; refer to the GCC manual for details. `-fsanitize=address` alone found several bugs in the various code bases I use.
We should provide instructions how to enable them to encourage their use, and maybe eventually run CI tests with sanitizers enabled.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/52Hardware state after transitions is not clearly defined2022-06-14T15:31:05+02:00Laurent PetreHardware state after transitions is not clearly defined### Summary
<!--- Summarize the bug encountered concisely -->
The state of the VFAT and event builder after the "Halt" transition are not set to a non running state. We need to establish and document if this is the desired behavior, pos...### Summary
<!--- Summarize the bug encountered concisely -->
The state of the VFAT and event builder after the "Halt" transition are not set to a non running state. We need to establish and document if this is the desired behavior, possibly based on the official [RCMS function manager documentation](http://cmsdoc.cern.ch/cms/TRIDAS/RCMS/Docs/Manuals/manuals/level1FMFSM_1_10_2.pdf).
The fix can be applied before or after the migration to the new architecture. In any case this work will have to be conducted.
### Steps to reproduce
<!--- How one can reproduce the issue - this is very important -->
1. Start a normal data-taking run
2. Click on the "Halt" button in GEMSupervisor
3. Look at the `DAQ_ENABLE` register and `CFG_RUN` registers
### What is the expected correct behavior?
<!--- What you should see instead -->
The status of the hardware should be clearly defined after each FSM transition.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
### Environment
- Version used: a9c84a4c220bd67c4158c81694667dc7ba8cc58c with !22 and !14
- Operation System: `cc7` on `gem904daq04`
<!--- ### Possible fixes -->
<!--- If you can, link to the line of code that might be responsible for the problem -->Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/51Hardware constants header2020-05-01T15:49:20+02:00Louis MoureauxHardware constants header### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
I noticed that the monitoring code uses constants such as `NOH` and `NAMC`. At least `gemonlinedb` has similar constants. This info...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
I noticed that the monitoring code uses constants such as `NOH` and `NAMC`. At least `gemonlinedb` has similar constants. This information should probably come from either:
* The hardware tree, if the information is supposed to be dynamic
* A centrally maintained header file, if the information is supposed to be static (eg the `12` in `Links connected: 5/12`)
Such a header should probably be part of the `core` library.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/28Calibration scans with tracking data format specs2022-06-14T15:31:04+02:00Camilla GalloniCalibration scans with tracking data format specs### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
This sums up [issue#230](https://github.com/cms-gem-daq-project/cmsgemos/issues/230) on GitHub.
Needed for the various scan types ...### Summary
<!--- Summarize what you would like to discuss -->
<!--- and what is the actual behavior -->
This sums up [issue#230](https://github.com/cms-gem-daq-project/cmsgemos/issues/230) on GitHub.
Needed for the various scan types is a definition of what the various bit fields mean in the output data format; current implementation in cmsgemos does the following:
`RunType: 4 bits [59:56] in AMC H2`:
* normal operations: 1
* latency data: 2
* "threshold" data : 3 (possibly redundant with latency, as only one parameter is changing over time in a given scan)
* s-curve data: 4, new type, two parameters change over the scan: channel and calibration pulse height
`RunParams 24 bits [55:32] in AMC H2`:
![RunParamsGEM](/uploads/e00d6bb7dc08114e9c62dc6ff144639f/RunParamsGEM.png)
Here
* P.S. = CFG_PULSE_STRETCH,
* isC = isCurrentPulse with 0 (1) = False (True),
* isExtTrig = isExternalTrig with 0 representing calibration mode and 1 would be an external trigger; if isExtTrig = 1 and CFG_CAL_DAC = 0 it would imply signals coming from externally injected charge (e.g. from particles in the detector or a signal generator injecting into the VFAT)
* selC = CFG_SEL_COMP_MODE; (0x0 = CFD, 0x1 = ARM, 0x2 = ZCC). If CFG_SEL_COMP_MODE = 0 we are in CFD mode and CFG_THR_ZCC_DAC is released on the ZCC after the ARM comparator is determined the pulse is over CFG_THR_ARM_DAC.
The implementation in `cmsgmeos` of the tracking data scans scans has followed what outlined in the python script [trackigDataCalibrationScan.py](https://gitlab.cern.ch/cmsgemonline/cmsgemos/snippets/1157) (tested in http://cmsonline.cern.ch/cms-elog/1089564) without the usage of the calibration data format.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/23gemrpc module structure2022-06-14T15:31:06+02:00Laurent Petregemrpc module structure### Summary
The `gemrpc` module is special in the sense that its interface is devised to be called from the client machine while the implementation itself must be compiled for a back-end board/acceleration board. During the migration, t...### Summary
The `gemrpc` module is special in the sense that its interface is devised to be called from the client machine while the implementation itself must be compiled for a back-end board/acceleration board. During the migration, the minimum amount of changes was made in order to shorten the downtime. Moreover the best design requires very careful consideration.
Here is a non-exhaustive list of constraints to take into consideration before starting an actual implementation:
* As any other `cmsgemos` module, the `gemrpc` module follows the hierarchy convention. Therefore its interface should live in the `gem::rpc` namespace. This is not currently the case.
* `gemrpc` is the first module to provide private header files, i.e. headers files which are not meant to be used by other modules and that live in the same directory as the source files. However, the simple migration creates confusing situation, although technically valid. Different header files exist with the same name in both the `interface` and `src` directory, e.g. `gemprpc/interface/utils.h` and `gemrpc/src/utils.h`. The former can be included from any module, including `gemrpc` itself with `<gem/rpc/utils.h>` while the latter can be include only from within the `gemrpc` module with relative paths (`"utils.h"`).
A better design would consist to renamed one of the two files sharing the same name. The actual implementation of public and private functions can (should?) also be split in different source files.
* `gemrpc` modules are based on the `wiscrpcsvc` framework which provides the ability to load different RPC module at run-time. This functionality has been abused within the `ctp7_modules` (now `gemrpc`) due to the multiple inter-dependencies between modules. Moreover, the `xhal` compile-time checks are defeated by the the fact that the right module needs to be manually loaded at compile-time.
Different approaches exist. One could consist in the creation of static libraries which are combined together as RPC modules. Another approach can be to build a single RPC module, containing all the RPC methods. This single module can be built directly or result from the combination of multiple static libraries.
* Apart from the remote interface, one might want to create binaries running directly on the back-end board (e.g. in the to be created `gemrpc/tools` folder). Such binaries, compiled either statically or dynamically, could require access to a larger interface than what the remote RPC methods provide. In this case, there would be two interfaces: 1 remote main interface and 1 "local" interface for specific tools.
Whether we chose to support different interfaces has a deep impact on the `gemrpc` modules structure. The simplest way to go may to only provide 1 remote interface and checks whether it is sufficient for the local tools to be created.
Another possibility would be to review the export mechanism and move away from functors to functions explicitly exported through the use of macros. This would provide the advantage to have uniform calls whether the function is exported, but also would allow to provide interface header file with both local and remote RPC methods.
Other constraints probably have to be taken into account to find the best design.