From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dT5mF-0006ty-Ib for qemu-devel@nongnu.org; Thu, 06 Jul 2017 08:21:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dT5mC-0000kc-CC for qemu-devel@nongnu.org; Thu, 06 Jul 2017 08:20:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36610) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dT5mC-0000kX-36 for qemu-devel@nongnu.org; Thu, 06 Jul 2017 08:20:56 -0400 From: Markus Armbruster References: <2c9645b5dce991f7a324dc2b61e2553e08230a9f.1499276048.git.alistair.francis@xilinx.com> <87r2xuay5h.fsf@dusky.pond.sub.org> <20170706080741.GB3988@redhat.com> <87lgo14xgs.fsf@dusky.pond.sub.org> <20170706114509.GL3988@redhat.com> Date: Thu, 06 Jul 2017 14:20:51 +0200 In-Reply-To: <20170706114509.GL3988@redhat.com> (Daniel P. Berrange's message of "Thu, 6 Jul 2017 12:45:09 +0100") Message-ID: <87lgo1lpss.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [RFC v3 2/3] qemu-error: Implement a more generic error reporting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: alistair23@gmail.com, Alistair Francis , philippe@mathieu-daude.net, qemu-devel@nongnu.org "Daniel P. Berrange" writes: > On Thu, Jul 06, 2017 at 01:27:15PM +0200, Markus Armbruster wrote: >> "Daniel P. Berrange" writes: >> >> > On Thu, Jul 06, 2017 at 08:15:54AM +0200, Markus Armbruster wrote: >> >> Alistair Francis 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 >> > >> >> > 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 : to :error: makes recognizing error messages a bit easier, but it also makes them even longer. Can't we make do with recognizing :? If SPICE babbles to stderr, it needs a gag.