Re: [PATCH v6 25/27] util: add support for formatting a program name in messages

Daniel P. Berrangé <[email protected]> writes:

> On Thu, Feb 19, 2026 at 11:08:45AM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé <[email protected]> writes:
>> 
>> > 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.
>> 
>> Why?
>
> Looking again, arguably that is fixing a pre-existing bug
>
> The current code is:
>
>     if (!monitor_cur() && g_get_prgname()) {
>         error_printf("%s:", g_get_prgname());
>         sep = " ";
>     }
>     switch (cur_loc->kind) {
>     case LOC_CMDLINE:
>         argp = cur_loc->ptr;
>         for (i = 0; i < cur_loc->num; i++) {
>             error_printf("%s%s", sep, argp[i]);
>             sep = " ";
>         }
>         error_printf(": ");
>         break;
>     case LOC_FILE:
>         error_printf("%s:", (const char *)cur_loc->ptr);
>         if (cur_loc->num) {
>             error_printf("%d:", cur_loc->num);
>         }
>         error_printf(" ");
>         break;
>     default:
>         error_printf("%s", sep);
>     }
>
>
> Notice how we honour "sep" for LOC_CMDLINE but ignore
> it for LOC_FILE.

This works exactly as intended.  To illustrate, add

    error_report("test, ignore");

to qdev_device_add(), then:

    $ cat t.cfg
    [device]
      driver = "usb-kbd"
    $ qemu-system-x86_64 -S -display none -machine usb=on -device usb-kbd -readconfig t.cfg -monitor stdio
    QEMU 10.2.50 monitor - type 'help' for more information
    qemu-system-x86_64: -device usb-kbd: test, ignore
    qemu-system-x86_64:t.cfg:2: test, ignore
    (qemu) device_add usb-kbd
    test, ignore

The format

    program:sourcefile:lineno: message

conforms to the GNU Coding Standards at
<https://www.gnu.org/prep/standards/standards.html#Errors>, and matches
common practice.

> With the program name printing moved out into a separate
> function, the space is always printed. No change for
> LOC_CMDLINE, but new whitespace for LOC_FILE.
>
> Should have changed this in a separate patch.
>
>> >       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
>> >
>> > When adding this the '-msg program-name=on|off' option is
>> > introduced, so that the program name (which is enabled by
>> > default) can be supressed if desired. This could be useful
>> > if '-msg guest-name=on' is being used as a more informative
>> > identifier.
>> 
>> Separate patch?
>
> It is a bit of a borderline decision, but I felt the knob to turn it
> off should be in the same patch that force enables it.

Peter objected to making the logs more verbose by default, and I think
he has a point.  Perhaps having errors and logs share a general format
is useful anyway, and perhaps making it even more configurable is as
well.  I figure we'd need separate configuration for logs and for error
messages.

Let's get to rough consensus before we debate the finer points like this
one.

>> > Reviewed-by: Richard Henderson <[email protected]>
>> > Signed-off-by: Daniel P. Berrangé <[email protected]>
>
> With regards,
> Daniel