Re: [Qemu-devel] TCG plugins and the GPL (was: [PATCH v4 00/54] plugins for TCG)

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> On Thu, 12 Sep 2019 at 11:07, Alex Bennée <address@hidden> wrote:
>> Peter Maydell <address@hidden> writes:
>> > Wait, what? From my perspective the whole point of the plugin
>> > interface is that it should be stable, in that at least there's
>> > a good chance that a plugin you built will work against multiple
>> > versions of QEMU, and if it doesn't then it should fail with
>> > a reasonable error message telling you to update. I'm not
>> > sure we should be landing the plugins infrastructure if we
>> > don't have that much stability.
>>
>> There is a big fat blurry line between "set in stone" and "not requiring
>> you to re-engineer the plugin every QEMU release". I'm saying we should
>> reserve the right to extend and change the plugin API as required but
>> the expectation would be the plugins will continue to work the same way
>> but maybe with tweaks to the API hooks to support additional features.
>>
>> It's also a pretty young interface so I would expect some evolution once
>> it is released into the field.
>
> Sure. But I think we should document that we at least intend to
> have some approximation to a compatability/deprecation policy
> here, and some mechanisms for versioning so you get a helpful
> error rather than weird misbehaviour if your plugin is too old.
>
>> One problem with the anti-license circumvention measures being suggested
>> is it will mean having to recompile plugins for any given release.
>
> Why should we do this? I think this is making life hard for our
> users for no good reason. We *do* have this check for modules,
> because a module is just a random .so that can do anything in
> QEMU. I thought we had the TCG-plugin interface much more locked
> down than that?

It is, there are only a few set calls the plugin can make into QEMU,
mostly to register callbacks to events. Currently it can examine the
state of the system (again through the API) but can't change it's
behaviour (although a register access interface has been requested
although I'd initially intended to make it read only).

>
> thanks
> -- PMM


--
Alex Bennée