Wed 28 Feb 2007 09:12:45 AM UTC, comment #10:
>> 2) drop the dyn lib into appropriate place
>Are such places defined anywhere?
>If not, I'd go for
>/opt/tsp/lib
>/usr/local/lib
>/usr/lib
>/lib
>~/.tsp/lib
>+ LD_LIBRARY_PATH
I agree with those locations with some
others like:
/opt/tsp/plugins
$HOME/.tsp/plugins
$TSP_PLUGINS_PATH if it is defined.
We should agree for search order to
be able to handle priority
I would suggest:
$TSP_PLUGINS_PATH
$HOME/.tsp/lib
$HOME/.tsp/plugins
/opt/tsp/plugins
/opt/tsp/lib
Those PATH and env var may (?should?) be used
for all kind of TSP forthcoming plugins
(BB plugins, Targa Plugins, TSP Core plugins).
>The process would then be:
>foreach (dir) {
>try to open a lib named librequest_XYZ.so
>foreach (lib) {
>dlopen(lib)
>try to dlsym(TSP_XYZ_request),
>if (sym defined)
>register_handler(TSP_XYZ_request)
>}
>}
Yes I agree with this scheme, but we should handle
the case of multiple instance of same lib found
in several places something more like:
for each (dir)
try to open a lib named librequest_XYZ.so
liblist.add_if_unique(librequest_XYZ.so)
..
then go on with previous process.
we should agree on naming convention for those lib/plugins.
As a sidenote I designed "request handler API"
in order to be able to 'hot-add' request handler
the idea is to trigger dyn lib load with something
like a SIGHUP handler (like most daemon do)
that would rescan for no already
loaded dynlib and then call
TSP_provider_rqh_manager_refresh
If we want to achieve this (which may be too much :))
the process should include a test in order to avoid
to load the same library twice.
In the end since this mechanism is clearly DANGEROUS for
the average real time provider, the default behavior should
be not to handle the "hot-plug" behavior.
|