Re: RFC: Lightweight tracing mechanism

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 23 May 2017, at 12:55, Victor Toso <victortoso@xxxxxxxxxx> wrote:

On Tue, May 23, 2017 at 11:51:01AM +0200, Christophe Fergeau wrote:

or something like glib (SPICE_XXX_DEBUG=alignment:foo:bar)

Just to point out that we have a bug for this [0] and IMHO it would be
the best approach but it would take some effort to have it besides the
glib that we would need is 2.50 (current required is 2.36)
[0] https://bugs.freedesktop.org/show_bug.cgi?id=91838
These seems to suggest the usage of glib for more refined control.
Pavel also recently commented on having some trouble with --spice-debug and SPICE_DEBUG and…
Would be helpful if you had recap Pavel problems. I don't remember.
For what it’s worth, I’ve implemented in several of my own projects a low-key tracing facility which for Spice would basically look like this:

Specifically:

- Define available traces in spice-traces.def file, e.g.:

// SPICE_TRACE(name, default_value, info)
SPICE_TRACE(foo, false, “Talk about foo")
SPICE_TRACE(bar, true, “A bar is a good thing, enabled by default")
#undef SPICE_TRACE

- Declare a structure holding one bit per trace flag, as follows:

extern struct spice_traces {
#define SPICE_TRACE(name, init, info) bool name:1;
#include “spice-traces.def”
} spice_traces;

- Initialize it in log.c, as follows:

struct spice_traces spice_traces = {
#define SPICE_TRACE(name, init, info) init,
#include “spice-traces.def"
};

- In log.c, add a function to deal with passing trace options either from command-line or environemnt

- In log.h, add macros to quickly test traces:

#define TRACE(name) (spice_traces.name)
#define IFTRACE(name) if (TRACE(name))
#define spice_trace(name, …) IFTRACE(name) spice_debug(__VA_ARGS__)

- In spice-option.c, add code to deal with testing the options.

Would you find this useful? The most difficult part being to connect that to existing tracing mechanisms to avoid replication of traces, while at the same time ensuring that the existing enabling mechanisms work as before.


Christophe
The main questions are:
- what are the original problems exactly?
- why your solution is good in your opinion?
- did you try other options (like Marc-andre' suggested) ?

Reading the code is not clear where exactly you implemented the different domains
suggested by the bug report. Did you just coded SSL as an example?
Also you introduced a new "TRACE" logging level; why DEBUG was not enough?

Frediano

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]