[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: |
Zhao Liu |
Subject: |
Re: [RFC] util/error-report: Add "error: " prefix for error-level report |
Date: |
Sat, 30 Mar 2024 01:15:25 +0800 |
Hi Paolo,
On Fri, Mar 29, 2024 at 12:10:17PM +0100, Paolo Bonzini wrote:
> Date: Fri, 29 Mar 2024 12:10:17 +0100
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: Re: [RFC] util/error-report: Add "error: " prefix for error-level
> report
>
> On Fri, Mar 29, 2024 at 10:37 AM <no-reply@patchew.org> wrote:
> > > 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.
>
> Unfortunately, this is the reason why you _cannot_ do what this patch does.
>
> For example:
>
> error_reportf_err(local_err, "Disconnect client, due to: ");
> error_report("terminating on signal %d", shutdown_signal);
>
> This should not be prepending "error" - it's not an error.
So I feel these 2 cases maybe should use info_report()?
> error_report_once("%s: detected read error on DMAR slpte "
>
> This is a guest error, so "error:" is probably not a good idea (it
> should use qemu_log_mask).
Yes, here I can do a cleanup.
> And so on. :(
error_report() and its variants have 2600+ use cases, and it's
impossible to distinguish whether ther're appropriate or not.
Thanks for your explanation, I understand this is not workable,
since there is too heavy the debt to sort out error_report().
Regards,
Zhao