Stefan Hajnoczi <stefa...@redhat.com> writes: > On Thu, Jul 23, 2020 at 03:29:03PM +0200, Christophe de Dinechin wrote: >> This patch is a simple example showing how the recorder can be used to >> have one "topic" covering multiple entries. Here, the topic is "lock", >> the idea being to have the latest lock changes for instance in case of >> a crash or hang. >> >> Here are a few use cases: >> >> * Tracing lock updates: >> RECORDER_TRACES=lock qemu >> * Showing lock changes prior to a hang >> RECORDER_TRACES=lock qemu & >> # Wait until hang >> killall -USR2 qemu # This will trigger a dump >> * Graphic visualization of lock states: >> RECORDER_TRACES="lock=state,id" qemu & >> recorder_scope state >> # Hit the 't' key to toggle timing display >> # Hit the 'c' key to dump the screen data as CSV >> cat recorder_scope_data-1.csv > > Dan raised a good point regarding integrating recorder functionality > behind the tracetool interface. > > On the other hand, I would like to see where this goes so that we have > enough experience to design the tracetool interface, if necessary. > > Therefore I am for merging this as-is and taking action when it's clear > that duplication is taking place.
Sounds like we should not yet commit to a stable external interface. The monitor command is HMP only. Not a stable interface. A QMP command would have to be marked experimental with the customary x- prefix. The environment variable is an external interface of the recorder library. Attempting to police such interfaces of libraries we use seems futile.
