qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 02/15] target-ppc: Move PPC_DUMP_CPU to trans


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2 02/15] target-ppc: Move PPC_DUMP_CPU to translate.c
Date: Mon, 25 Feb 2013 15:28:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

Am 25.02.2013 14:48, schrieb Alexander Graf:
> 
> On 25.02.2013, at 14:02, Andreas Färber wrote:
> 
>> Am 25.02.2013 13:49, schrieb Alexander Graf:
>>>
>>> On 21.02.2013, at 05:24, Andreas Färber wrote:
>>>
>>>> There's an opcode handler field dependent on PPC_DUMP_CPU without which
>>>> the build fails.
>>>>
>>>> Signed-off-by: Andreas Färber <address@hidden>
>>>> ---
>>>> target-ppc/translate.c      |    1 +
>>>> target-ppc/translate_init.c |    1 -
>>>> 2 Dateien geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
>>>>
>>>> diff --git a/target-ppc/translate.c b/target-ppc/translate.c
>>>> index 2ac5794..2e74e45 100644
>>>> --- a/target-ppc/translate.c
>>>> +++ b/target-ppc/translate.c
>>>> @@ -33,6 +33,7 @@
>>>>
>>>> /* Include definitions for instructions classes and implementations flags 
>>>> */
>>>> //#define PPC_DEBUG_DISAS
>>>> +#undef PPC_DUMP_CPU
>>>
>>> #undef?
>>
>> // is not permitted. :)
>> Alternative would be /* #define ... */
>>
>> Just edit the line to your liking. :)
> 
> The current coding style for debug defines is // #define DEBUG_FOO. It don't 
> think it makes sense to deviate from that notion unless we do it 
> consistently. And to do that, we need to consistentify the handling first 
> which your patches do.

Having gone through all targets I can guarantee you there is no
consistent style ATM: ppc and other pre-checkpatch.pl targets use
//#define ...; s390x uses /* #define ... */ and some others use #undef
..., the latter being less typing both for me and for enabling.
So if you dislike #undef, I suggest you edit it as //#define.

> So IMHO I'd rather like to see a patch changing the style to whatever people 
> prefer after this set is through.

Feel free to send one... :-)

BTW generally I would rather see the relevant ..._DUMP_... data exposed
as QOM properties on the CPU object; that would allow to inspect data on
demand rather than dumping a whole bunch always-or-never. But I have
doubts about exposing the current fields 1:1 - we'd have to decide on
sensible property names and values then.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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