On Thu, Jul 27, 2023 at 03:13:25PM +0200, Łukasz Bartosik wrote: > Thunderbolt tracing is a lightweight alternative to traditional > thunderbolt debug logging. While thunderbolt debug logging is quite > convenient when reproducing a specific issue, it doesn't help when > something goes wrong unexpectedly. There are a couple of reasons why > one does not want to enable thunderbolt debug logging at all times: > > 1. We don't want to overwhelm kernel log with thunderbolt spam, others > want to use it too But doesn't the dynamic debug infrastructure allow this today? > 2. Console logging is slow Slow how? > Thunderbolt tracing aims to solve both these problems. Use of > the thunderbolt tracefs instance allows to enable thunderbolt > logging in production without impacting performance or spamming > the system logs. > > To use thunderbolt tracing, set the thunderbolt.trace module parameter > (via cmdline or sysfs) to true: > :: > eg: echo true > /sys/module/thunderbolt/parameters/trace Why yet-another module parameter? Why is this required? > Once active, all log messages will be written to the thunderbolt trace. > Once at capacity, the trace will overwrite old messages with new ones. > At any point, one can read the trace file to extract the previous > thunderbolt messages: > :: > eg: cat /sys/kernel/tracing/instances/thunderbolt/trace > > The thunderbolt trace instance is subsystem wide, so if you have multiple > devices active, they will be adding logs to the same trace. This just uses the existing logging functionality and ties it into the trace functionality, right? If so, why not do this for all printk messages, why should this be unique to thunderbolt? Normally with tracing, you enable specific tracepoints that you add, not just "all dev_*() messages", are you sure this will actually help? thanks, greg k-h
