Hi Jakub, I continued playing with plugins for libgomp, and I have several questions regarding that:
1) Would it be ok, at least for the beginning, if we'd look for plugins in a folder, specified by some environment variable? A plugin would be considered as suitable, if it's named "*.so" and if dlsym finds a certain set of functions in it (e.g. "device_available", "offload_function" - names are subjected to change of course). 2) We need to perform all libgomp initialization once at the first entry to libgomp. Should we add corresponding checks to all GOMP_* routines or should the compiler add calls to GOMP_init (which also needs to be introduced) by itself before all other calls to libgomp? 3) Also, would it be ok if we store libgomp status (already initialized or not) in some static variable? I haven't seen such examples in the existing code base, so I don't sure it is a good way to go. 4) We'll need to store some information about available devices: - a search tree with data about mapping - corresponding plugin handler - handlers for functions from the corresponding plugin - maybe some other info I guess that's a bad idea to store all this data in some static-sized global variables, and it's better to dynamically allocate memory for that. But it implies that we need to care about deallocation, which should be called at some moment on the program end. Shouldn't we introduce something like GOMP_deinitialize and insert calls to it during the compilation? 5) We mentioned that similar to a tree data-structure for storing info about mapping. Am I getting it correctly, that currently there is no such data-structure at all and we need to design and implement it from scratch? -- Thanks, Michael
