[Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 19.03.2015 um 23:34 schrieb Lex Trotman:
> On 19 March 2015 at 09:16, Thomas Martitz <kugel at rockbox.org> wrote:
> There is no other way of loading C shared libraries and registering them as
> plugins.
>
> Doesn't Geany already load dlls local and extract the symbols it wants
> via dlsym()?
>
> dlsym() takes an argument of the loaded dll handle, so it can't access
> the wrong library.


Yes, there is no problem in this if accesses go through dlsym with the 
appropriate library handle. Global namespace collisions can occur of 
symbols exported by multiple shared libraries are accessed the normal 
way, either by geany or plugins. This happens in the current loader, as 
plugins access their geany_plugin pointer (but does not happen under my 
new loader). As we use RTLD_LOCAL so we have no problems here either, 
however it is still nice to have to minimize the amount of globals 
exported by the plugin.



> API/ABI just a typo :)  Note that allowing the plugin to make this
> decision means it has to have a way of overriding the default >= test
> you have moved into geany.
>

I can't follow this.


>> But indeed, the API version could be passed to geany_load_module() to allow
>> for the above. Passing the abi version is pretty useless as the plugin will
>> only load with one specific abi anyway so it can't adapt.
>>
>>
>>> Also it would be good to consider the semantics of API and ABI since
>>> there are some conditions where we cannot express a change in the
>>> interface except for the hammer of an ABI break.
>>
>> We should be able with the new loader mechanism, since we learn about the
>> plugin's minimum API version. Now we can not only deny based on the ABI
>> version but also based on the minimum API (we could possibly deny loading
>> plugins which are written against too old API version).
> The decision of "too old" needs to be made by the plugin, Geany
> doesn't know what the plugin uses, that a plugin declares "I can run
> with any API newer than 123" doesn't mean it actually uses 123.  It is
> just being friendly and saying "I can run with older Geany's as well".
>


The plugin may know it better, that's why I follow your suggestion and 
pass Geany's API version to geany_load_module.

I was saying that we could deny loading plugins that report 123 as their 
minimum if we made an incompatible API break in 130 like removing a 
function all together. While it's true that 123 doesn't mean it uses 
that very function, Geany could be conservative and deny loading. (I 
know this was a bad example because we bump the ABI for removed 
functions, and plugins that use the removed function would not recompile 
successfully, but you get the idea).

Best regards