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
