On Thu, Jun 8, 2017 at 10:56 AM, Markus Armbruster <arm...@redhat.com> wrote: > Alistair Francis <alistair.fran...@xilinx.com> writes: > >> 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? > > So far we simply use error_printf() for such things. > > A function to report a warning would let us report them more uniformly, > but only if we actually use it uniformly. In other words, adding one > without also converting the existing warnings to use it would create yet > another open-ended incremental conversion job. Are we up to it?
Yeah! Why not. I am happy to give it a shot changing some errors to warnings. First thing though, what is the format for printing warnings? Thanks, Alistair >