[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC][PATCH v3 00/24] instrument: Let the user wrap/ove
From: |
Lluís Vilanova |
Subject: |
Re: [Qemu-devel] [RFC][PATCH v3 00/24] instrument: Let the user wrap/override specific event tracing routines |
Date: |
Wed, 01 May 2013 16:34:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Stefan Hajnoczi writes:
> On Sun, Apr 28, 2013 at 09:25:15PM +0200, Lluís Vilanova wrote:
>> Stefan Hajnoczi writes:
>>
>> > On Fri, Apr 26, 2013 at 02:15:46PM +0200, Lluís Vilanova wrote:
>> > Advanced users will have to modify the QEMU source.
>>
>> >> > Basically I think putting a stable API in place here isn't going to fly.
>> >> > In terms of the tracing subsystem I don't mind, but I think it's a
>> >> > question for the larger QEMU community.
>> >>
>> >> What are you referring to as an API? The tracing events and their
>> >> signatures?
>>
>> > The interface that dynamic instrumentation libraries use to interact
>> > with QEMU. That means "stable" tracing events plus any operations that
>> > libraries can perform (stop/stop vcpu, peek/poke memory, dirty bitmaps,
>> > MMU, interrupts, etc).
>>
>> Not all events require being "stable", just a few that I established as
>> "abstract" and relate to some very generic guest state (which in their most
>> basic form can be boiled down to 5). As for the rest of the API and more
>> controversial events, as I said I have no problem in maintaining a separate
>> branch.
> Can you split the work into two patch series:
> 1. Target-independent TCG events (e.g. vbbl_begin)
> 2. "custom" trace backend that links custom C trace event handler
> functions - but without dynamic libraries or stable API.
> It loses the dynamic library and stable API features but would be easy
> to merge.
Yes, I was thinking about sending a mail along those lines too. This basically
entails two series (2nd and 4th in my current branch):
* Support for tracing events at TCG code generation time (basically
auto-generating per-event TCG helpers - trace_<event>_tcg -, which call the
actual tracing event - trace_<event> -).
* The events themselves (calls to trace_<event>_tcg).
I can then maintain instrumentation support and its public API on a separate
branch.
Still, I'm not sure when I'll have time for this, as it will require moving a
few patches among the series I have now (and readjusting their contents).
Thanks,
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