gemrpc module structure
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
gemrpcmodule follows the hierarchy convention. Therefore its interface should live in the
gem::rpcnamespace. This is not currently the case.
gemrpcis 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
gemrpc/src/utils.h. The former can be included from any module, including
<gem/rpc/utils.h>while the latter can be include only from within the
gemrpcmodule with relative paths (
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.
gemrpcmodules are based on the
wiscrpcsvcframework which provides the ability to load different RPC module at run-time. This functionality has been abused within the
gemrpc) due to the multiple inter-dependencies between modules. Moreover, the
xhalcompile-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/toolsfolder). 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
gemrpcmodules 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.