Hi, Jeff Hostetler wrote: > This patch series contains a new trace2 facility that hopefully addresses > the recent trace- and structured-logging-related discussions. The intent is > to eventually replace the existing trace_ routines (or to route them to the > new trace2_ routines) as time permits. I've been running with these patches since last October. A few thoughts: I like the API. The logs are a bit noisy and especially wide. For my use, the function name is not too important since we can get that from the file and line number. Should we have a way to omit some fields, or is that for post-processing? We don't find the JSON easy to parse and would prefer a binary format. When I apply the patches, Git complains about whitespace problems (trailing whitespace, etc). Aside from that kind of easily correctible issue (trailing whitespace), I'd be in favor of taking these patches pretty much as-is and making improvements in tree. Any objections to that, or do you have other thoughts on where this should go? If that sounds reasonable to you, I can send a clean version of these based against current "master". If I understand correctly, then https://github.com/jeffhostetler/git branch gvfs-trace2-v4 contains some improvements, so as a next step I'd try to extract those as incremental patches on top. What do you think? Thanks, Jonathan