[Spice-devel] RFC: Lightweight tracing mechanism

[Marc-André Lureau]

Hi

----- Original Message -----
> Top remark: here is what I expected to see discussed when I shared the code.
> 

Sending a github link isn't really sharing code. It is not our cmmon practice, so we can't easily review/discuss it.

> 1. What categories do we want?
> 2. How do spread the categorization work?

Very good questions, no easy answer. This is I think some kind of ontological problem, and many things could actually belong to many "categories". Imho, in code, the file/unit is the natural split. If a unit is doing several things, it could be split. If a category is shared in several units, it means we have sub-categories (ex: widget, wiget_egl, widget_cairo etc)

> 3. How much do today’s developers depend on existing output?

A lot obviously (it doesn't mean we can just keep adding whatever log there).

> 4. What categories do we request e.g. in bug reports (IOW, what should
> --spice-debug select)

Imho, SPICE_DEBUG=1 (or --spice-debug for spice-gtk) should log all categories (from production or debug build). It is just simpler that way.

> 5. What tracing options and tweaks are potentially dangerous for end-users
> (e.g. what could expose security information)

Log should never allow to expose a security sensitive information in production builds. We are not doing that well in spice-gtk logs for ex, in particular logging key scancode isn't a good idea.

> 6. Consequently, what tracing options do hide in release builds, current POV
> ranging from “as many as possible" (me) to “none of them” (you)

It's not easy to identify, imho logging key scancode should only be in debug builds for ex.

> 7. What are the existing hard-coded parameters? Explicit (e.g. 400ms delay in
> the server) or implicit (e.g. unbounded memory usage)
> 8. Among these, which ones would we like to tweak?

No idea, you would have to grep the code for hardcoded values.

> 9. Among those we want to tweak, which ones would deserve dedicated options
> or env variables, which ones would be perfectly OK with a more generic
> option like the -t I proposed.

If you want to add more options to spice-gtk or spice-sever, feel free to propose it, but be aware it will be frowned up for the reason already discussed in the thread.

> It did not go as planned, but if you have time, I think these are interesting
> questions.
> 

Yes, they are interesting, that's why this thread is hot. And I hope my contribution helps. For the rest of your question, there is too much misunderstanding, and you are very time consuming, I'll try to answer later. (btw, I didn't meant to attack you personally when I say "you can't use gdb" for ex, but you said you couldn't easily use it on macos iirc - and yes I strongly believe that logging is too often used as a poor-man way of debugging - if you feel offended, you shouldn't as I believe you know how to use it).

I agree with you on log category / filtering and adding more debugging. I strongly disagree on using another facility to tweak runtime than existing option parsing or environment variables, or coupling it with logging. I proposed an alternative to add log categories/filtering which I believe fits better and simplify our code. 

So let's send patches, and let's review them please.

thanks