From: "Daniel P. Berrange" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: alistair23@gmail.com,
Alistair Francis <alistair.francis@xilinx.com>,
philippe@mathieu-daude.net, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v3 2/3] qemu-error: Implement a more generic error reporting
Date: Thu, 6 Jul 2017 14:10:28 +0100 [thread overview]
Message-ID: <20170706131028.GM3988@redhat.com> (raw)
In-Reply-To: <87lgo1lpss.fsf@dusky.pond.sub.org>
On Thu, Jul 06, 2017 at 02:20:51PM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
>
> > On Thu, Jul 06, 2017 at 01:27:15PM +0200, Markus Armbruster wrote:
> >> "Daniel P. Berrange" <berrange@redhat.com> writes:
> >>
> >> > On Thu, Jul 06, 2017 at 08:15:54AM +0200, Markus Armbruster wrote:
> >> >> Alistair Francis <alistair.francis@xilinx.com> writes:
> >> >>
> >> >> > This patch converts the existing error_vreport() function into a generic
> >> >> > qmesg_vreport() function that takes an enum describing the
> >> >> > information to be reported.
> >> >> >
> >> >> > As part of this change a new qmesg_report() function is added as well with the
> >> >> > same capability.
> >> >> >
> >> >> > To maintain full compatibility the original error_report() function is
> >> >> > maintained and no changes to the way errors are printed have been made.
> >> >> > To improve access to the new informaiton and warning options wrapper functions
> >> >> > similar to error_report() have been added for warnings and information
> >> >> > printing.
> >> >> >
> >> >> > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
> >> >
> >> >> > diff --git a/util/qemu-error.c b/util/qemu-error.c
> >> >> > index 1c5e35ecdb..63fdc0e174 100644
> >> >> > --- a/util/qemu-error.c
> >> >> > +++ b/util/qemu-error.c
> >> >> > @@ -179,17 +179,29 @@ static void print_loc(void)
> >> >> >
> >> >> > bool enable_timestamp_msg;
> >> >> > /*
> >> >> > - * Print an error message to current monitor if we have one, else to stderr.
> >> >> > + * Print a message to current monitor if we have one, else to stderr.
> >> >> > * Format arguments like vsprintf(). The resulting message should be
> >> >> > * a single phrase, with no newline or trailing punctuation.
> >> >> > * Prepend the current location and append a newline.
> >> >> > * It's wrong to call this in a QMP monitor. Use error_setg() there.
> >> >> > */
> >> >> > -void error_vreport(const char *fmt, va_list ap)
> >> >> > +void qmsg_vreport(report_type type, const char *fmt, va_list ap)
> >> >> > {
> >> >> > GTimeVal tv;
> >> >> > gchar *timestr;
> >> >> >
> >> >> > + switch (type) {
> >> >> > + case REPORT_TYPE_ERROR:
> >> >> > + /* To maintain compatibility we don't add anything here */
> >> >>
> >> >> I feel the comment isn't going to be useful in the future. Let's drop
> >> >> it.
> >> >
> >> > Do we really need to care about compatibility of the precise way we output
> >> > error messages. It has never been something we call a "stable API", as we
> >> > don't guarantee error message text will remain the same across releases. So
> >> > anyone relying on scraping QEMU stderr to match some error message has always
> >> > been liable to break.
> >> >
> >> > IOW, just add an "error: " prefix to the text
> >>
> >> I agree the error message format isn't ABI.
> >>
> >> But what would adding "error: " buy us?
> >
> > It would clearly distinguish errors from any other output on stderr, which
> > may not be error related (for example SPICE commonly pollutes stderr with
> > lots of messages).
>
> Changing the current error message format
>
> <TIMESTAMP><PROGNAME>:<LOCATION><MSG>
>
> to
>
> <TIMESTAMP><PROGNAME>:<LOCATION>error: <MSG>
>
> makes recognizing error messages a bit easier, but it also makes them
> even longer. Can't we make do with recognizing <PROGNAME>:?
I'm not convinced 7 extra characters is a big deal compared with the
size of the timestamps, program name, location & error message itself.
We'll already have such a prefix for info & warnings, so consistency is
good IMHO.
If line length is a concern, perhaps we should make the error printing
function able to intelligently line wrap at 80 chars, taking into account
the size of the metadata (timestamp, program, location, msg type prefix).
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 :|
next prev parent reply other threads:[~2017-07-06 13:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-05 17:36 [Qemu-devel] [RFC v3 0/3] Implement a warning_report function Alistair Francis
2017-07-05 17:36 ` [Qemu-devel] [RFC v3 1/3] util/qemu-error: Rename error_print_loc() to be more generic Alistair Francis
2017-07-06 2:36 ` Thomas Huth
2017-07-05 17:36 ` [Qemu-devel] [RFC v3 2/3] qemu-error: Implement a more generic error reporting Alistair Francis
2017-07-06 2:42 ` Thomas Huth
2017-07-06 6:15 ` Markus Armbruster
2017-07-06 8:07 ` Daniel P. Berrange
2017-07-06 11:27 ` Markus Armbruster
2017-07-06 11:45 ` Daniel P. Berrange
2017-07-06 12:20 ` Markus Armbruster
2017-07-06 13:10 ` Daniel P. Berrange [this message]
2017-07-06 14:44 ` Markus Armbruster
2017-07-06 18:45 ` Alistair Francis
2017-07-05 17:36 ` [Qemu-devel] [RFC v3 3/3] char-socket: Report TCP socket waiting as information Alistair Francis
2017-07-06 2:46 ` Thomas Huth
2017-07-06 6:18 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170706131028.GM3988@redhat.com \
--to=berrange@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=alistair23@gmail.com \
--cc=armbru@redhat.com \
--cc=philippe@mathieu-daude.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).