Hugh Leather wrote:
Aye up all,
I've now been reading through some of the list archive. Some of the
posts were about how to tell GCC which plugins to load. I thought I'd
tell you how libplugin does it.
Thanks for the nice explanation. I'm not sure to understand exactly how
libplugin deals with adding passes; apparently, the entire pass manager
(ie gcc/passes.c) has been rewritten or enhanced. Also, I did not
understood the exact conceptual differences between libplugin & other
proposals. Apparently libplugin is much more ambitious.
So we now have many plugin proposals & experiments. However, we do know
that there are some legal/political/license issues on these points (with
the GCC community rightly wanting as hard as possible to avoid
proprietary plugins), that some interaction seems to happen (notably
between Steering Committee & FSF), that the work is going slowly
(because of lack of resource & labor & funding? at FSF).
My perception is that the issues are not mostly technical, but still
political (and probably, as Ian Taylor mentioned it in
http://gcc.gnu.org/ml/gcc/2008-09/msg00442.html a lack of lawyer or
other human resources at FSF, which cost much more than any reasonable
person could afford individually). I actually might not understand why
exactly plugins are not permitted by the current GCC licenses.
What I don't understand is
* what exactly do we call a plugin? I feel (but I am not a lawyer) that
(on linux) it is any *.so file which is fed to dlopen. I'm not able to
point what parts of the GCC license prohibit that (I actually hope that
nothing prohibits it right now, if the *.so is compiled from GPLv3-ed
FSF copyrighted code. the MELT branch is doing exactly that right now).
* will the runtime license be working for Christmas 2008. [some messages
made me think that not, it is too much lawyer work; other messages made
me a bit more optimistic; I really am confused]. Of course, I don't want
any hard date, but I am in the absolute darkness on the actual work
already done on improving the runtime license, and even more on what
needs to be fixed. Also, I have no idea of the work involved in writing
new licenses (I only know that the GPLv3 effort lasted much more than
one year). Did I say that I am not a lawyer, and not understanding even
the basic principles of US laws (or perhaps even French ones)?
* what kind of intrusiveness do we want for the plugin machinery. Do we
want it to be clean and hence to touch a lot of files (in particular the
details of passes & the pass manager), or do we first want some quick
and dirty plugin trick merged into the trunk, even if it is imperfect?
* what is the plugin machinery useful for? Only adding optimisation
passes, or much more ambitious (adding new front ends, back ends, targets)?
* what is the interaction between the plugin machinery & the rest of GCC
(e.g. GGC, dump files, )
* what is the granularity plugins are wanted or needed for? Only whole
passes, or something smaller than that (e.g. some specific functions
inside specific passes)?
* who really want plugins to happen quick, and which company would
invest money [not only code] on that?
* what host system do we want the plugin to work with? Is libtool dyn
loader enough? Could every non static symbol inside cc1 be visible to
the plugin?
* do we really want one single (fits all) plugin machinery inside GCC?
My feeling is that a lot of various technical efforts has already being
put into plugins, but that the future runtime license may (or not)
impact technicalities (perhaps making some proposed technical solutions
impossible). I really don't understand what is the hard limit, i.e. what
the FSF or the Steering Committee wants to avoid exactly (obviously
proprietary plugins implementing new machine targets are unwanted, but
what else; is the goal to only permit FSF copyrighted GPLed plugins;
what would be the review policy of code going into plugins?)?
I've got no idea of how would it be hard to make any plugin system
accepted into the GCC trunk, and when could that work begins to start
(i.e. when to send plugin patches to gcc-patches@). I tend to believe
that it the main issue now. Are plugin patches supposed to be welcome
-on the gcc-patches@ mailing list, for trunk acceptance- when GCC goes
back in stage1? Will the first plugin patches (submitted to gcc-patches@
for acceptance into trunk) be huge or tiny patches? Technically both are
possible (of course with different goals & features).
I even don't know what legally a plugin is. For instance, in my MELT
branch code is indeed dlopen-ed, but [currently] the C code of the
plugin is generated (by the plugin itself) from MELT lisp-like files,
which are all inside the MELT branch (GPL-ed, FSF copyrighted) Perhaps
that does not even count, from a legal point of view, as a plugin? [I
really hope I am not doing unknowingly illegal things on the MELT
branch; to calm everyone, of course every line of code there is GPLv3
licenced, FSF copyrighted - even generated code... so I hope that I am
not guilty... :-) ].
My guess is that the most visible effect of plugins could be perhaps a
tiny side effect: some code could be practically used in gcc, with GPL
licence (or LGPL?) inside GCC [since it is dlopen-ed] without being FSF
copyrighted, but perhaps the goal of the steering committee is to avoid
that.
And I even don't understand who is deciding what on the plugin issues &
the runtime license issue.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
