qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trace_FOO_tcg bit-rotted?


From: Vilanova, Lluis
Subject: Re: trace_FOO_tcg bit-rotted?
Date: Tue, 27 Apr 2021 13:00:21 +0000
User-agent: Evolution 3.38.3-1

El dv. 23 de 04 de 2021 a les 16:14 +0100, en/na Alex Bennée va
escriure:
> > > > > > > > 
> > As Stefan pointed out, this means plugin writers will have to write
> > their own TCG tracing code. Hopefully, the plugin API can be
> > extended
> > to integrate with qemu's logging backend (it seems qemu_plugin_outs
> > goes somewhere else),
> 
> qemu_plugin_outs goes out via the logging backend - but not the
> tracing
> subsystem. Do you think being able to emit tracepoints to simpletrace
> or
> the dtrace/ftrace would be a useful extension to the API.

It seems dtrace would be hard to "automatically" support unless all
plugin callbacks are kept in tracetool (since there is all the compile-
time generation). So maybe it's better to keep it simple and let plugin
writers decide if they want to support a specific backend by defining
whatever necessary on their own plugins.

Would plugins be able to hook into QEMU's backend to inform it of the
plugin-defined events when the plugin is loaded? (e.g., let dtrace know
about dtrace events in the plugin). I'm not sure how the external
dependencies work for all the various backends.


> 
> Do you have any documented uses of the trace subsystem that I could
> re-implement in TCG plugins by way of example? I have the feeling it
> has
> been used for academic papers but I haven't seen usage "in the wild".

I have not kept up with the plugin developments since I participated in
the discussion of this years ago. So unfortunately I cannot provide any
meaningful answers/help here.


Cheers,
Lluis

reply via email to

[Prev in Thread] Current Thread [Next in Thread]