On Thu, Feb 19, 2026 at 10:23:36AM +0000, Peter Maydell wrote: > On Wed, 11 Feb 2026 at 15:29, Daniel P. Berrangé <[email protected]> wrote: > > > > The error_report function can include the program name in any > > messages it prints. The qemu_log function has no equivalent > > behaviour. > > > > This introduces support for a "program name" in the new > > messages API, which will be included by default for all > > binaries. > > > > This change tweaks the output of the error_report function, > > adding a space between the program name and the location > > info. The qemu_log function will gain the program name. This > > can be easily seen with the 'log' trace backend, and how it > > is now more closely matching error_report output. > > > > Before: > > > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish -d > > 'trace:qcrypto*' > > qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x5584e13937f0 > > dir=fish > > qcrypto_tls_creds_get_path TLS creds path creds=0x5584e13937f0 > > filename=ca-cert.pem path=<none> > > qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No > > such file or directory > > > > After: > > > > # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish -d > > 'trace:qcrypto*' > > qemu-system-x86_64: qcrypto_tls_creds_x509_load TLS creds x509 load > > creds=0x5584e13937f0 dir=fish > > qemu-system-x86_64: qcrypto_tls_creds_get_path TLS creds path > > creds=0x5584e13937f0 filename=ca-cert.pem path=<none> > > qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No > > such file or directory > > On the other hand if you're using the logs for debugging > then you now have an extra big pointless prefix on them that > you have to turn off. Especially if you're logging to a file > that's a lot of extra garbage in the output. I'm not really > looking forward to now having to give QEMU an extra long > and unwieldy command line argument every time I want to > do debug or tracepoint logging. > > Why do we care about the qemu_log output matching the > error-report output? The logs are expected to be > quite frequent, to only be there if you've explicitly > turned them on, and to be usually directed to a log file.
Personally I never use the log-to-file facility. Instead typical use case is relying on the trace points 'log' facility as illustrated in the commit message example to dump to stderr for simple debugging, and having consistent formatting between the logs & errors is useful there. In effect this patch series is implicitly viewing the error report output as a being a variant of log output with a level of "ERROR", despite us having completely separate logic for logs vs errors internally. In this particular patch, I didn't especially have a use case for the program name in the log output, it instead of fell out of the general goal of using the same formatting logic for both subsystems. I'll think about how to alter this. > The error reporting is more likely to be infrequent, to > be on stdout, and to be important/fatal things. > > -- PMM > With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
