[vlc-devel] [RFC] Plugins CPU requirements

[jpd at videolan.org]

On Sat, Jan 09, 2010 at 11:17:47PM +0200, R?mi Denis-Courmont wrote:
> Le samedi 9 janvier 2010 23:07:25 M?ns Rullg?rd, vous avez ?crit :
> > "R?mi Denis-Courmont" <remi at remlab.net> writes:
> > > Le samedi 9 janvier 2010 16:03:04 R?mi Denis-Courmont, vous avez ?crit :
> > >> 2) Encode each CPU requirement through a dedicated exported symbol. For
> > >> instance, if a plugin exposes vlc_plugin_MMX, then it requires MMX.
> > >> Generating the module bank will be a tiny bit slower.
> > >
> > > It seemed nice. But this could break if the shared object automatically
> > > runs code when it is loaded (C++ plugins do that for instance).
> > 
> > Another good reason to avoid C++.
> 
> That's not the question here. If the library has
> constructors/destructors function, this scheme will fail, at least in
> theory. C++ is just one case; you can get the same with C too.

Then forbid on-load code for plugins that need cpu specifics. For those
modules that don't need optimizations VLC will (perhaps belatedly) not
detect special symbols and it can proceed. For those that do need them,
if there is no on-start code all is still fine. For those that need
features and need on-start code, it falls onto them to make sure the
plugin doesn't have cpu-dependent on-start code and instead handles the
dlopen() of underlying libraries with on-start code if and only if the
loading can proceed. This is convoluted and dirty but only troublesome
in a special case with two prerequisites (need features AND need on-load
code execution).

This of course also requires that VLC trusts its modules, but then it
also has to trust dlopen() et al. As long as there are no third party
modules this is tricky but fine.


Hooking back to an earlier idea, f.ex. moz plugins use code to export
(and import) data tables full of pointers to code. That should work
across most if not all shared object / dll systems, and should
be reasonably fast for detection and so on, but also pushes the
responsibility to avoid on-load code definively into the plugin.


> > >> 3) Encode CPU requirements in the name or path of each plugin.
> > >> For instance, if a plugin file name ends in "_mmx.$(LIBEXT)" it
> > >> requires MMX.
> > >
> > > This does not quite work with more than one requirement for a
> > > single plugin.

Depending on the encoding scheme it could work, assuming a sufficiently
large maximum file name. Subdirectories have the same problem, so the
solution would be similar.