[suggestion] dynamically-loaded backend

[mdorier]

A feature that would be nice to add to IOR and mdtest is the possibility to provide the name of an API in the following format: "LIB:/path/to/my/libbackend.so:symbol_aiori, providing the path to a shared library to dlopen and the name of a symbol representing the ior_aiori_t object to dlsym from that library.

This would allow storage system developers to implement an IOR backend in the form of a shared library shipped with their storage system's source, instead of having to fork IOR and add a backend in IOR's source.

I have started looking into the IOR code for the best way to implement this. One of the difficulties, I think, is that all the backends need to be available from the start in order to parse options.

[JulianKunkel]

Good thought. A problem with this is that dynamic library loading such as dlsym() isn't necessarily portable on all HPC systems. I reckon what we could do is to provide an aiori backend that would allow to load libraries, i.e., just routing calls through... That way we keep the current module structure hardbacked into the code while allowing for some use cases to route calls through... Would be easy to create e.g., a dlsym plugin and check if dlsym is available, if not, disable the build of this module...

[glennklockwood]

I agree, having a dlsym aiori is a nice way to add this functionality without affecting the existing backends.

[JulianKunkel]

To conclude, we look for someone to create such a DLSYM-AIORI implementation.
I think would be a nice first contribution.