Re: [PATCH 2/2] rust/hw/char/pl011/src/device: Implement logging

[Peter Maydell <peter.maydell@linaro.org>]

On Wed, 2 Apr 2025 at 14:28, Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Wed, Apr 02, 2025 at 09:33:16AM +0000, Bernhard Beschow wrote:
> > Am 31. März 2025 09:18:05 UTC schrieb "Daniel P. Berrangé" <berrange@redhat.com>:
> > >General conceptual question .....  I've never understood what the dividing
> > >line is between use of 'qemu_log_mask' and trace points.
> >
> > I *think* it's the perspective: If you want to see any issues, regardless
> > of which device, use the -l option, i.e. qemu_log_mask(). If, however,
> > you want to see what a particular device does, use tracepoints.
>
> I guess I'd say that the latter ought to be capable of satisfying the
> former use case too, given a suitable trace point selection. If it
> can't, then perhaps that's telling us the way we select trace points
> is insufficiently expressive ?

Yeah; you can turn on and off a tracepoint, and you can select
them by wildcard, but there's no categorization of them
(into eg "this is basically the equivalent of a debug printf"
vs "this is something that is a guest error you probably
want to know about"). There's also no way to say "turn on
this logging with one switch, and it will print multiple lines
or more than one thing" (at least not in the spirit of what
the tracepoint API expects; you could have a trace_in_asm
tracepoint that took a "%s" and output whatever you liked as
the string, of course). And debug-logging is more documented:
'-d help' shows what you can turn on and off and has at least
a brief description of what it is you're getting. For tracepoints
you're hoping that the name is vaguely descriptive and also
hoping that the device/subsystem/etc named its tracepoints in
a way that lets you usefully wildcard them.

Also, the qemu_log() logging assumes "we're sending text to
a logfile, we can format e.g. register dumps and disassembly
as arbitrary laid out plaintext". That's fine if your tracepoint
backend is also "we just send the text to a logfile/etc", but
I don't know if all of the tracepoint backends would be so happy
with that.

thanks
-- PMM