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 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
