On 8/8/19 12:49 PM, Daniel P. Berrangé wrote: > On Wed, Aug 07, 2019 at 12:44:40PM +0530, Balamuruhan S wrote: >> Adds scripting interface with python library to call functions in >> python modules from Qemu that can be used to feed input externally >> and without recompiling Qemu that can be used for early development, >> testing and can be extended to abstract some of Qemu code out to a >> python script to ease maintenance. > > I admit the use case is interesting, but this is opening a can of > worms... > > Historically the project has held the view that we do not wish > to have an mechanism to support loading out of tree code into the > QEMU process. Much previously talk was around dlopen'd C plugins, > but dynanically loaded Python plugins are doing the same thing > at a conceptual level. > > We didn't wish to expose internals of QEMU in a plugin API to > avoid having any kind of API promise across releases. > > There was also the question of licensing with plugins opening > the door for people to extend QEMU with non-free/closed source > functionality. > > While this series only uses the plugin for one fairly obscure > device, once a python plugin feature is intergrated in QEMU > there will inevitably be requests to use it in further areas > of QEMU. > > IOW, acceptance of this patch is a significant question for > the project, and a broader discussion point, than just this > PPC feature patch series.
Since performance is not an issue, we can use a QMP-PyMMIO bridge. Most of the functions required are already exposed, Damien completed the missing ones in his 'FAULT INJECTION FRAMEWORK' series: https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06230.html Maybe we simply need a clearer (better documented) QMP 'MMIO' API?
