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

[BALATON Zoltan]

On Wed, 2 Apr 2025, 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'd say that traces are like debug printfs that you don't normally want to 
see but may be interesting for developers for debugging a specific device 
model or QEMU part so you can enable the relevant ones for that device or 
part. Logs are something you want to notify the user or admin about and is 
not tracing internal operation of a device. But there may be some overlap 
as some logs could be converted to traces but they are under log for 
historical reasons as previously there were debug printfs controlled by 
defines in devices that were later converted to traces and logs that could 
be controlled in run time which were used for some traces before trace 
points existed. Then were probably kept as logs just to not change the 
command line because it's easier to type -d in_asm then say -trace 
enable="tcg_in_asm" or something like that.
Regards,
BALATON Zoltan

> > The latter can be
> > optionally built to feed into qemu log, as well as the other dynamic trace
> > backends.
> The use of qemu_log() in qemu_log_mask() seems like an implementation detail to 
> me. Theoretically, qemu_log_mask() could use a different backend if this got 
> implemented, and wouldn't require code changes throughout QEMU.
>
> Best regards,
> Bernhard
>
> > Is there a compelling reason to use 'qemu_log', that isn't acceptable for
> > trace probe points ?
> >
> > This is an indirect way of asking whether qemu_log_mask should be exposed
> > to rust, or would exposing tracing be sufficient ?
> >
> > With regards,
> > Daniel