On Wed, Jun 7, 2017 at 11:03 PM, Markus Armbruster <arm...@redhat.com> wrote: > Alistair Francis <alistair.fran...@xilinx.com> writes: > >> On Wed, Jun 7, 2017 at 12:19 AM, Markus Armbruster <arm...@redhat.com> wrote: >>> Paolo Bonzini <pbonz...@redhat.com> writes: >>> >>>> On 06/06/2017 18:30, Alistair Francis wrote: >>>>>> >>>>>> This is somehow confusing. I don't think it is worth having another >>>>>> qemu_log_stderr() function rather than using error_report() but this very >>>>>> call might deserve a comment explaining this unusual use. What do you >>>>>> think? >>>>> >>>>> The problem with stderr is that this isn't an error. Some uses of QEMU >>>>> (inside Eclipse for example) flag everything printed on stderr as red >>>>> which confuses users that they are seeing an error when they really >>>>> aren't. >>>> >>>> But they are wrong. >>> >>> Concur. We also print warnings and informational messages to stderr. >>> >>> We should make errors easy to recognize. Fortunately, error_report() >>> prints errors to stderr in a rigid format. Unfortunately, error >>> messages bypassing error_report() still exist in places. We suck. >>> >>> The format is >>> >>> timestamp-if-enabled progname ':' location message >>> >>> timestamp-if-enabled is normally empty. With -msg timestamp=on, it's >>> the current time in ISO 8601 format, followed by a space. >>> >>> progname is the program name (main()'s argv[0]). >>> >>> location is either empty, or a reference to the command line or a >>> configuration file. >>> >>> See error_vreport() for details. >> >> Ok, but this isn't an error, it's more information. So it sounds like >> we should still print to stderr but not print in the format described >> above? > > Yes. > > I explained the error message format to show how to distinguish actual > errors from other stuff.
Sorry, I should have been more clear. I meant we should not use the error_report() function here. I don't think we have any warning_report() function though, is that something worth having?
