On 9/11/25 14:10, Markus Armbruster wrote:
* Tracing
- Control: off by default, enabled with -trace per trace point (and
also -d trace: --- I find that duplication bizarre)
The series adding both "-trace enable=..." and "-d trace:" justifies it
like this
(https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05808.html):
---
add a "-d trace:foo" option that is a synonym for "-trace foo";
this makes the new functionality more discoverable to people used
to "-d", makes it available for user-mode emulation (which does
not have -trace), and is somewhat nice if you want to enable both
tracepoints and some other "-d" flag (patch 9). When globbing
it is also less susceptible to unwanted shell expansion.
For example, you can trace block device I/O and save the result
to a file just by adding "-trace bdrv_aio_*,file=trace.txt", or
correlate it to guest PCs with "-d exec,nochain,trace:bdrv_aio_*".
---
These days, user-mode emulation does have -trace (commit 6533dd6e111,
"trace: [linux-user] Commandline arguments to control tracing").
Also, "-trace file=..." is a synonym of -D if the log backend is
enabled, so it made sense to have a synonym also for "trace enable="
within "-d".
· "log" wraps around util/log.c's always-on logging
(FWIW this used to be "stderr" and it was not enabled by default; this
ensured that tracing was used a lot less even by developers :)).
* Spreading logs over multiple destinations can make the order hard to
determine.
-D splits util/log.c from util/error-report.c.
-d tid further splits per thread.
Splitting per thread feels fairly redundant once the prefix includes
the thread name. Thread names is easier to make sense of than numeric
thread IDs in the split filenames.
https://lore.kernel.org/all/[email protected]/
says "this can be extremely helpful in debugging user-only threads".
* In my view, util/log.c consists of three layers. Form bottom to top:
* Logging messages: qemu_log()
* Control of what to log ("log items"): qemu_log_mask()
* Address filtering: qemu_log_in_addr_range()
The bottom layer is also used by trace backend "log".
Makes sense.
* Tracing vs. "log items"
Tracing and "log items" both provide opt-in logging.
Why do we have two? Feels like an accident to me.
One is structured and the other is not. Structure is both a curse and a
blessing: a blessing because it allows plugging in external tools, a
curse because it limits what you can write.
Address range filtering is only used with "log items". It could just
as easily be used with tracing.
Agreed that address range filtering could be added to tracetool and
supported by tracepoints (though probably it does not make sense for all
of them, and maybe only makes sense for very few due to TCG's preference
for log items).
Paolo
