Re: Defining a common plugin machinery

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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} ***