qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] util/error-report: Add "error: " prefix for error-level report


From: Thomas Huth
Subject: Re: [RFC] util/error-report: Add "error: " prefix for error-level report
Date: Wed, 27 Mar 2024 13:36:07 +0100
User-agent: Mozilla Thunderbird

On 27/03/2024 12.46, Zhao Liu wrote:
From: Zhao Liu <zhao1.liu@intel.com>

When vreport() was introduced, there was no prefix for error-level
(REPORT_TYPE_ERROR) report. The original reason is "To maintain
compatibility we don't add anything here" as Alistair said in his
RFC v3 series [1].

This was done in the context of inheriting the original error_report()
interface without the prefix style. And it was also useful to have a
means of error handling, such as exit(), when error occurs, so that the
error message - the most serious level - can be noticed by the user.

Nowadays, however, error_report() and its variants have a tendency to be
"abused": it is used a lot just for the sake of logging something more
noticeable than the "warn" or "info" level, in the absence of
appropriate error handling logic.

But, in the use case above, due to the lack of a prefix, it is in fact
less informative to the user than warn_report()/info_report() (with
"warn:" or "info: " prfix), which does not match its highest level.

Therefore, add "error: " prefix for error-level report.

[1]: https://lore.kernel.org/qemu-devel/87r2xuay5h.fsf@dusky.pond.sub.org/#t

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
  util/error-report.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/util/error-report.c b/util/error-report.c
index 6e44a5573217..e981c0b032f0 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -213,6 +213,7 @@ static void vreport(report_type type, const char *fmt, 
va_list ap)
switch (type) {
      case REPORT_TYPE_ERROR:
+        error_printf("error: ");
          break;
      case REPORT_TYPE_WARNING:
          error_printf("warning: ");

Sounds like a good idea to me, but I think you should then also remove
the hard-coded "error:" strings in the various error_reports():

$ grep -ri 'error_report.*"error:'
migration/block-dirty-bitmap.c:        error_report("Error: block device name is not 
set");
migration/block-dirty-bitmap.c:                error_report("Error: Unknown bitmap 
alias '%s' on node "
migration/block-dirty-bitmap.c:                error_report("Error: unknown dirty 
bitmap "
migration/block-dirty-bitmap.c:        error_report("Error: block device name is not 
set");
target/i386/kvm/kvm.c:        error_report("error: failed to set MSR 0x%" PRIx32 " 
to 0x%" PRIx64,
target/i386/kvm/kvm.c:        error_report("error: failed to get MSR 0x%" 
PRIx32,
util/vhost-user-server.c:        error_report("Error: too big message request: %d, 
"
accel/hvf/hvf-all.c:        error_report("Error: HV_ERROR");
accel/hvf/hvf-all.c:        error_report("Error: HV_BUSY");
accel/hvf/hvf-all.c:        error_report("Error: HV_BAD_ARGUMENT");
accel/hvf/hvf-all.c:        error_report("Error: HV_NO_RESOURCES");
accel/hvf/hvf-all.c:        error_report("Error: HV_NO_DEVICE");
accel/hvf/hvf-all.c:        error_report("Error: HV_UNSUPPORTED");
accel/hvf/hvf-all.c:        error_report("Error: HV_DENIED");
monitor/hmp-cmds.c:        error_reportf_err(err, "Error: ");
hw/arm/xlnx-zcu102.c:        error_report("ERROR: RAM size 0x%" PRIx64 " above max 
supported of "
hw/block/dataplane/xen-block.c:        error_report("error: unknown operation 
(%d)", request->req.operation);
hw/block/dataplane/xen-block.c:        error_report("error: write req for ro 
device");
hw/block/dataplane/xen-block.c:            error_report("error: nr_segments too 
big");
hw/block/dataplane/xen-block.c:            error_report("error: first > last 
sector");
hw/block/dataplane/xen-block.c:            error_report("error: page crossing");
hw/block/dataplane/xen-block.c:        error_report("error: access beyond end of 
file");
hw/rdma/rdma_backend.c:            rdma_error_report("Error: Not a MAD request, 
skipping");
hw/s390x/s390-skeys.c:        error_report("Error: Setting storage keys for pages 
with unallocated "
hw/s390x/s390-skeys.c:        error_report("Error: Getting storage keys for pages 
with unallocated "
hw/usb/bus.c:        error_report("Error: no usb bus to attach usbdevice %s, "
gdbstub/gdbstub.c:            error_report("Error: Bad gdb register numbering for 
'%s', "

 Thomas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]