TS-implemented Configurator subtrees

[okt-galaktionov]

There are some parts of HW/SW configuration that are too vendor-specific to be implemented in the upstream TE Test Agent. Sometimes there is simply no standard way of enabling a given feature, so multiple implementations would need to coexist and some logic would be required to decide which implementation is to be used at a given moment in time. This would put a lot of complexity and maintenance burden on TE, especially considering that some of these settings are unlikely to be useful outside of a single test suite.

Another approach would be to develop a generic mechanism in the Test Agent that would allow test suites to provide their own implementations of specific Configurator object handlers. This way the test suite would be responsible for maintaining these handlers and get some flexibility of implementation as well.

What would be the best way to implement something like this?

[ol-arteman]

Actually, there is only one obstacle to implementing this. Currently, Configurator subtrees are initialized by explicitly calling a set of *_init functions from the Agent's main. This need not be the case, the initialization may be performed by ELF constructors, and here are two options:

• link the test suite-specific libraries as .a libraries (in the same way as testsuite-specific RPC calls are implemented) and add needed Configurator subtress from ELF constructors. This requires almost no changes to the existing code, however, there is an important gotcha here: the static libraries must be linked with -Wl,--whole-archive or else constructors won't work reliably. Meson does support it, however, our build system probably not, so it would need some tweaking
• link the test-suite specific libraries as .so plugins and make the agent load them dynamically - this functionality would need to be implemented in the Agent, naturally. The second way seems to me a bit more flexible and reliable, however, both ways should ultimately work and I have no really strong opinion on which is better.

In both cases, however, care must be taken to ensure that the builtin Configurator subtrees are still properly registered. Perhaps, the right way is to eliminate those explicit init calls altogether and use the same constructor-based initialization with TE-defined Configurator subtrees as well.

[okt-kostik]

Actually Oleg has implemented somewhat similar

We'll try to publish something.