On Thu, 12 Sep 2019 at 11:07, Alex Bennée <alex.ben...@linaro.org> wrote: > Peter Maydell <peter.mayd...@linaro.org> 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? thanks -- PMM
