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 can understand if someone thinks this is not a desired feature for QEMU [1], but not including it into upstream will just turn it into a patch-based feature that will rapidly fail to apply on top of upstream QEMU. [1] Of course, I will still contribute support for guest tracing, as well as the guest events I added. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth