> On 6 Jun 2017, at 20:45, Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel