qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] target/mips: implement QMP query-cpu-definit


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH v2] target/mips: implement QMP query-cpu-definitions command
Date: Tue, 19 Feb 2019 22:03:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0

Hi Eric,

On 2/19/19 9:12 PM, Eric Blake wrote:
> On 2/19/19 1:15 PM, Aleksandar Markovic wrote:
>> From: Pavel Dovgalyuk <address@hidden>
>>
>> This patch enables QMP-based querying of the available CPU types for
>> MIPS and MIPS64 platforms.
>>
>> Signed-off-by: Pavel Dovgalyuk <address@hidden>
>> Signed-off-by: Aleksandar Markovic <address@hidden>
>> Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
>> Tested-by: Philippe Mathieu-Daudé <address@hidden>
>> ---
> 
>> +++ b/qapi/target.json
>> @@ -499,7 +499,7 @@
>>              'static': 'bool',
>>              '*unavailable-features': [ 'str' ],
>>              'typename': 'str' },
>> -  'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_I386) 
>> || defined(TARGET_S390X)' }
>> +  'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_I386) 
>> || defined(TARGET_S390X) || defined(TARGET_MIPS)' }
> 
> Hmm. Long line; however, the argument to 'if' is pasted literally to an
> #if directive, which would break if we added newlines in the middle.
> And we can't use literal newlines in the middle of a JSON string.  About
> the only thing I could think of that might allow for more manageable
> line lengths would be permitting:
> 
> 'if': [ 'defined(TARGET_PPC)',
>         'defined(TARGET_ARM)' ...]

Can this be:

'if': [
        'defined(TARGET_PPC)',
        'defined(TARGET_ARM)',
        ...
      ]

?

> where the QAPI generator would in turn form the disjunction of supplying
> the || between each term when the 'if' is an array of strings. But that
> feels like a lot of effort for little gain compared to just living with
> the long lines.

Single line looks easier thus less bug prone.

Multiline improves git diff/blame.

The former looks safer.



reply via email to

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