On 8/8/19 6:15 PM, Philippe Mathieu-Daudé wrote: > 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
will look at this approach and try using QMP-PyMMIO bridge. Thank you all for review and suggestions. > > Maybe we simply need a clearer (better documented) QMP 'MMIO' API? >
