Re: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototype

[Pavel Dovgalyuk]

> From: Alex Bennée [mailto:address@hidden
> Peter Maydell <address@hidden> writes:
> 
> <snip>
> >> Now I can see arguments against it from an interface complexity point of
> >> view but I think plugins should get access to the TCG functions so they
> >> can generate their own op sequences if need be and not have to call a
> >> helper at all if they don't need to.
> >
> > I strongly disagree -- plugins should not have access to details
> > of QEMU internals that might change from version to version, and
> > definitely not access to generating their own TCG code.
> 
> In terms of the wider problem about exposing internals that might change
> from version to version I wonder if we should care? Is the plugin API
> one where we should provide ABI stability or should we take the approach
> that Linux does and say if your code lives out-of-tree then it's your
> problem to keep up if/when we change.

Then one can just omit the plugins and embed the analysis code into QEMU.
The idea behind the plugins is making the maintenance less time-consuming
by providing the stable interface.

Pavel Dovgalyuk