[Top][All Lists]

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

[Qemu-devel] Re: [PATCH -v2 1/2] Log reset events

From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH -v2 1/2] Log reset events
Date: Fri, 16 Jan 2009 14:35:22 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Jan Kiszka wrote:
> Kevin Wolf wrote:
>> Laurent Desnogues schrieb:
>>> On Fri, Jan 16, 2009 at 1:14 PM, Kevin Wolf <address@hidden> wrote:
>>> [..]
>>>>> @@ -159,6 +159,12 @@ static void cpu_reset_model_id(CPUARMState *env, 
>>>>> uint32_t id)
>>>>>  void cpu_reset(CPUARMState *env)
>>>>>  {
>>>>>      uint32_t id;
>>>>> +
>>>>> +    if (qemu_loglevel_mask(CPU_LOG_RESET)) {
>>>>> +        fprintf(logfile, "CPU Reset (CPU %d)\n", env->cpu_index);
>>>>> +        cpu_dump_state(env, logfile, fprintf, 0);
>>>> Shouldn't that be qemu_log() and log_cpu_state() now?
>>> Yes. Sorry Jan :)
> Well, the patch description misled me a bit ("global s/loglevel &
> X/qemu_loglevel_mask(X)/"), but I also could have checked more carefully
> what actually changed.
>>> A trick to check things are done properly is to make sure you
>>> don't ever use logfile or loglevel variables.
>> Maybe qemu_log() should be a function rather than a macro? Then loglevel
>> and logfile could be static and the build would break if you try to use
>> them outside the logging code.
> Sounds good (function-like macros are for corner cases only).
> I will try to make logfile/loglevel static and fix my patch accordingly.

Making logfile and loglevel static means enforcing a function call just
to check if we perform logging. Would the additional overhead be
acceptable for all qemu_log* spots? Unless maintainers tell me "yes", I
will not touch this part for now.


Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

reply via email to

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