Re: [PATCH v3 17/20] util: add support for formatting a workload name in messages

["Dr. David Alan Gilbert" <dave@treblig.org>]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Thu, Sep 11, 2025 at 08:27:36PM +0000, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > > The error_report function can include the guest name in any
> > > messages it prints. The qemu_log function has no equivalent
> > > behaviour.
> > > 
> > > This introduces support for a "workload name" in the new
> > > messages API, which in the case of system emulators will
> > > be the guest name. The possibility of defining a workload
> > > name for other binaries is left as an exercise for the
> > > future.
> > > 
> > > This change has no impact on the output of the error_report
> > > function, but will change the qemu_log function. 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 -msg guest-name=on -name blah -object tls-creds-x509,id=t0,dir=fish -d 'trace:qcrypto*'
> > >   qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55b3af3fd870 dir=fish
> > >   qcrypto_tls_creds_get_path TLS creds path creds=0x55b3af3fd870 filename=ca-cert.pem path=<none>
> > >   blah qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such file or directory
> > > 
> > > After:
> > > 
> > >   # qemu-system-x86_64 -msg guest-name=on -name blah -object tls-creds-x509,id=t0,dir=fish -d 'trace:qcrypto*'
> > >   blah qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55b3af3fd870 dir=fish
> > >   blah qcrypto_tls_creds_get_path TLS creds path creds=0x55b3af3fd870 filename=ca-cert.pem path=<none>
> > >   blah qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such file or directory
> > > 
> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > 
> > Are you going to want to escape that? I see later you're adding []'s around it,
> > which makes it feel like you want to end up with it parsable, but if some nasty
> > person does:
> > 
> > -name ']})🐧({['
> > 
> > then things get confusing; I guess you're hoping that whoever calls qemu will
> > be careful not to allow that.
> 
> I was considering the log output to be human targetted, rather
> than something to be parsed. IOW, if users want to confuse
> themselves with wierd names, that's their own (unwise) decision.
> 
> If we added ecaping of the name, it'd probably even more difficult
> to read for a human, even if we make it a bit easier for humans ?
> 
> TL;DR: do we care about parseability here, or just humans reading ?

If it's just humans that's fine; if anywhere were documenting the output
format then it should probably have a warning.

Dave

> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/