Hi
----- Original Message -----
>
> > 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 constrants 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.
Ok, that's where the confusion came from. Your solution is not a a complete
tracing solution (like dtrace, ust etc), but rather a way to have runtime
debugging enabled/disabled/listed by categories, which can be used on top of
glog/fprintf etc. However, it overlaps with other tracing solution that
provides different means.
As I said, I think filtering/greping log is actually more powerful, for the
current logs. And structured logs will also improve the situation (query/filter
on specific fields).
Now, for performance sensitive code, traditionally, #ifdef code is ok, but it
tends to linger and become obsolete. In spice-gtk, there is also
spice_util_get_debug(), but that will enable all extra logging/measurements and
may not optimal.
In all cases, I question the need for having such performance-sensitive code in
releases, or even in upstream code, as it tends to become useless when the
performance problem is considered solved, or when the people looking at the
esoteric logs move to something else (based on my experience).
Imho, none your examples seem performance-sensitive to me, and could be in the
debug log by default. If you would trace some value inside a tight loop, or hot
path, for ex, that would be different. But who would really need it and be able
to process that kind of data, without extra tools for analysis etc? That's
where systemdtap/lttng etc are good at, I believe.
> 2. “tweaks”, which are integer values, used to tweak the behaviour of the
> code, e.g. to trigger rare / corner case behaviours.
Now this is even further away from tracing. Imho, existing argument parsing
(for end-users) or environment parsing (mostly for devs, or global tweaks) are
quite fine here. We could better document the existing environment variables,
beside that, what does "tweaks" bring?
>
> 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.
Yes, it does, thanks!
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
