On Wed, Dec 7, 2011 at 18:54, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 12/07/2011 12:51 PM, Peter Maydell wrote: >> >> 2011/12/7 Lluís Vilanova<vilan...@ac.upc.edu>: >>> >>> Anthony Liguori writes: >>> [...] >>>> >>>> Why should this analyzer live outside of QEMU in the first place? I >>>> fail to see >>>> the rationale for that other than not wanting to do the work of making >>>> it >>>> suitable for upstream consumption. >>> >>> >>> For the same reason that SystemTap lets you add user-provided code into >>> the >>> trace hooks, you never know what the user actually wants. The difference >>> is that >>> when dealing with traces that require a high bandwidth, different people >>> may be >>> interested on analyzing different events and under different conditions, >>> and >>> having a JIT in QEMU comes in handy to optimize the traces. This includes >>> the >>> generation of extra tracing code at translation time (e.g., I generate >>> checks in >>> TCG to establish when I want to trace a specific event, and someone else >>> may >>> just want to increment a counter using TCG code). >>> >>> Guest trace instrumentation turns QEMU into a highly-performant tool for >>> dynamic >>> binary instrumentation, with all the benefits that stem from QEMU >>> (support for a >>> myriad of target architectures, as well as support for both full-system >>> and >>> user-level applications). >> >> >> I think this *is* useful. However I also think that it *is* effectively >> defining an API for people writing this hook code, and as such we ought >> to do it properly if we're going to do it. (ie nail down what we are >> providing for hook authors and don't let them grub around in the internals >> otherwise). > > > I strongly suspect that you could define interfaces in QEMU such that you > could do most of what you want without needing to link any code against QEMU > itself.
I don't see linking as the problem, the instrumenting user who modifies QEMU needs to follow licensing if the result is ever distributed. But the API issue can be a problem. Reusing and extending tracepoints should help API stability from an instrumenting user point of view and a rich set of various static and dynamic tracepoint mechanisms should only be helpful for development of QEMU. But also I agree that the internals of QEMU shouldn't become an API for any user code which happens to access them. > This is probably a case where LUA integration might make a lot of sense. > > Regards, > > Anthony Liguori > >> >> -- PMM >> >> >
