[vlc-devel] [RFC] Plugins CPU requirements

Rémi Denis-Courmont remi at remlab.net
Sat Jan 9 22:17:47 CET 2010


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.

> >> 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.
> >
> >> 4) Store optimized plugins in dedicated directories, just like GNU ld
> >> (e.g. /usr/lib/i686/cmov vs /usr/lib). If a plugin is in an mmx/
> >> (sub)directory, it requires MMX. It would be easier if optimized plugins
> >> were already in separate source code directories - they aren't.
> >
> > Thus, ^this^ seem like the only option left. Opinions?
> 
> How does this work if features are not a strictly expanding set and a
> module has multiple requirements?

Either way, concatenation or subdirectories would be needed. There are no such 
plugins to this day.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis



More information about the vlc-devel mailing list