> On 6 Jun 2017, at 20:45, Marc-André Lureau <marcandre.lur...@redhat.com>
> wrote:
>
> I don't think any of these measurements couldn't be reported accurately with
> a regular log or structured log. Thus I don't understand what problem you try
> to solve.
>
> Sorry, but I also have a hard time to understand what your tracing library
> does. Could you point to a simple example and short doc?
Probably should have started with that. I thought this was relatively obvious
from the code and the comments I had put in the initial mail. Apparently not,
sorry.
Purpose: The tracing / tweaking mechanism (not a library, just a couple of
macro and a multiply-included .def file) is to offer an easy, scalable,
consistent way to add debug code that is intended to stay in the code, and
provides generally useful, yet focused information or program behavior
alterations. Examples include: showing information about a specific subsystem
(memory), showing a specific kind of frequently used measurement (FPS, network
utilization), tweaking internal parameters eg. to make the system more easily
hit a corner case (e.g. put constraints on bandwidth or memory usage, tweak
image compression parameters, etc).
This mechanism lets you add two categories of configurable values in the code:
1. “traces”, which are boolean flags, named “traces" because they are most
often used to enable a specific set of runtime traces.
2. “tweaks”, which are integer values, used to tweak the behaviour of the code,
e.g. to trigger rare / corner case behaviours.
Traces and tweak can be configured wither using the command line, with the
--spice-trace or -t option (e.g. -t foo, -t foo=0, -t foo:bar:baz), or using
the SPICE_TRACES environment variable (similar syntax).
Traces and tweaks are defined in the spice-traces.def file using two macros,
SPICE_TRACE and SPICE_TWEAK. in this .def file, you give the name of the trace
or tweak, which must follow C syntax, the default / initial value for the trace
or tweak, and a documentation string that will be shown by the -t list option.
Here are some usage models:
1. Add focused printout (traces, probably the most frequent use case):
a. Add a SPICE_TRACE entry in spice-traces.def, so that your traces can
be activated with -t foo:
SPICE_TRACE(foo, 0, “Check for foos in the bar, and report how
many were found”)
b. Add the trace messages using spice_trace(foo, …):
spice_trace(foo, “Checked the presence of foos, found %d”,
foo_count());
c. Activate the trace by giving the -t foo option to spice or setting
SPICE_TRACES=foo.
2. Add a conditional behavior, e.g. report FPS statistics:
a. Add a SPICE_TRACE entry:
SPICE_TRACE(fps, 0, “Report frames per second”)
b. Add conditional code using IFTRACE:
IFTRACE(fps) {
frames++;
every (1 second) {
spice_trace(fps, “FPS=%d”, frames);
frames = 0;
}
}
c. When you are interested in getting the FPS stats from spice, just
add the -t fps option or set SPICE_TRACES=fps
3. Add configurable conditional code (e.g. a fault injector)
a. Add the required SPICE_TRACE entries:
SPICE_TRACE(kaboom, 0, “Inject random errors while receiving
packets”)
SPICE_TWEAK(kaboom_rate, 10, “Percentage of faulty packets
triggered’”);
b. Add conditional code to trigger your fault, e.g.
fault = false;
IFTRACE(kaboom) {
if (lrand48() % 100 <= TRACE(kaboom_rate)) {
fault = true;
}
}
c. Activate the fault injector with 25% failure rate by giving the -t
kaboom:kaboom_rate=25 option, or setting SPICE_TRACE=kaboom:kaboom_rate=25
Hope this helps.
Christophe
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
