qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH v6 04/29] hw/arm: Replace fprintf(std


From: Alistair Francis
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v6 04/29] hw/arm: Replace fprintf(stderr, "*\n" with error_report()
Date: Fri, 22 Dec 2017 12:58:53 -0800

On Fri, Dec 22, 2017 at 12:30 PM, Markus Armbruster <address@hidden> wrote:
> Alistair Francis <address@hidden> writes:
>
>> On Fri, Dec 22, 2017 at 9:17 AM, Thomas Huth <address@hidden> wrote:
>>> On 22.12.2017 16:37, Markus Armbruster wrote:
>>>> Second thoughts...
>>>>
>>>> Alistair Francis <address@hidden> writes:
>>> [...]
>>>>>  #include "qemu/osdep.h"
>>>>> +#include "qemu/error-report.h"
>>>>>  #include "qapi/error.h"
>>>>>  #include "qemu-common.h"
>>>>>  #include "cpu.h"
>>>>> @@ -1311,8 +1312,8 @@ static void omap_prcm_apll_update(struct 
>>>>> omap_prcm_s *s)
>>>>>      /* TODO: update clocks */
>>>>>
>>>>>      if (mode[0] == 1 || mode[0] == 2 || mode[1] == 1 || mode[1] == 2)
>>>>> -        fprintf(stderr, "%s: bad EN_54M_PLL or bad EN_96M_PLL\n",
>>>>> -                        __func__);
>>>>> +        error_report("%s: bad EN_54M_PLL or bad EN_96M_PLL",
>>>>> +                     __func__);
>>>>>  }
>>>>
>>>> This one's different: we neither exit() nor return a "failed" status to
>>>> the caller.
>>>>
>>>> We get here when the guest writes something funny to a certain
>>>> memory-mapped I/O register.  In other words, it's guest misbehavior, not
>>>> a user error.  I doubt it should be reported with error_report().
>>>> Peter, do we have a canonical way to report or log  guest misbehavior?
>>>
>>> qemu_log_mask(LOG_GUEST_ERROR, ...) ?
>>
>> That seems like the best option to me.
>
> Suggest:
>
> 1. Keep converting fatal errors (the ones that exit())
>
> 2. Keep converting recoverable errors (the ones that return failure)
>
> 3. You can leave the prints that are neither alone.  You can also
>    convert to logging or tracing, as appropriate, but that requires
>    understanding the code.
>
> Makes sense?

Does this apply to new patches after this series or to this series as
well? The series is mostly just mechanical find/replace. I really
don't want to have to dig through every patch to figure out what to
change/not change.

Alistair

>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]