On Thu, 11 Sept 2025 at 13:10, Markus Armbruster <arm...@redhat.com> wrote:
>
> - Control: off by default, enabled with -trace per trace point (and
> also -d trace: --- I find that duplication bizarre)
If you're a primarily-logging user it makes perfect sense:
I want to be able to control everything I log in one
place ("-d in_asm,exec,trace:gicv3*").
> * 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".
>
> * Tracing vs. "log items"
>
> Tracing and "log items" both provide opt-in logging.
>
> Why do we have two? Feels like an accident to me.
Partly this is because tracing is newer but it doesn't do the things
the 'log' facility does. In particular, with logging you enable
the category of things you want to see (e.g. "tell me about
anything where the guest does something we didn't implement")
whereas trace events have no such categorization.
Log messages don't have the weird restrictions that trace
events have that some of the backends impose (e.g. "no
floating point values").
Logging is easier to read and write because the format string is
right there in the source file, rather than having to be
separated out into the trace-events file.
-d also always works and does the same thing regardless
of what tracing backend QEMU was configured with.
> When to use which? I guess people pick whatever they're familiar
> with.
I use logging for "I want to get logs of what TCG is doing",
and for the "show me everything in this category" logging.
I use trace events for "I want to see what this device emulation
is doing".
> Would we be better off with just one? I wish...
>
> Which one? Clearly tracing, because tracing backends provide plenty
> of useful functionality "log items" lack.
But the reverse is also true, which is why we still have both.
-- PMM
