gemrpc 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, 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, thegemrpc
module follows the hierarchy convention. Therefore its interface should live in thegem::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 theinterface
andsrc
directory, e.g.gemprpc/interface/utils.h
andgemrpc/src/utils.h
. The former can be included from any module, includinggemrpc
itself with<gem/rpc/utils.h>
while the latter can be include only from within thegemrpc
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 thewiscrpcsvc
framework which provides the ability to load different RPC module at run-time. This functionality has been abused within thectp7_modules
(nowgemrpc
) due to the multiple inter-dependencies between modules. Moreover, thexhal
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.