qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 8/9] qapi: make 'if' condition strings simple identifiers


From: Markus Armbruster
Subject: Re: [PATCH v4 8/9] qapi: make 'if' condition strings simple identifiers
Date: Fri, 21 May 2021 14:02:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

marcandre.lureau@redhat.com writes:

> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> Change the 'if' condition strings to be C-agnostic and be simple
> identifiers.
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Tested-by: John Snow <jsnow@redhat.com>
> ---

[...]

> diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
> index c1cb6f987d..edaaf7ec40 100644
> --- a/docs/devel/qapi-code-gen.txt
> +++ b/docs/devel/qapi-code-gen.txt
> @@ -791,7 +791,7 @@ will then be guarded by #if STRING for each STRING in the 
> COND list.
>  Example: a conditional struct
>  
>   { 'struct': 'IfStruct', 'data': { 'foo': 'int' },
> -   'if': ['defined(CONFIG_FOO)', 'defined(HAVE_BAR)'] }
> +   'if': ['CONFIG_FOO', 'HAVE_BAR'] }
>  
>  gets its generated code guarded like this:
>  
> @@ -810,7 +810,7 @@ member 'bar'
>  
>  { 'struct': 'IfStruct', 'data':
>    { 'foo': 'int',
> -    'bar': { 'type': 'int', 'if': 'defined(IFCOND)'} } }
> +    'bar': { 'type': 'int', 'if': 'IFCOND'} } }
>  
>  A union's discriminator may not be conditional.
>  
> @@ -822,7 +822,7 @@ value 'bar'
>  
>  { 'enum': 'IfEnum', 'data':
>    [ 'foo',
> -    { 'name' : 'bar', 'if': 'defined(IFCOND)' } ] }
> +    { 'name' : 'bar', 'if': 'IFCOND' } ] }
>  
>  Likewise, features can be conditional.  This requires the longhand
>  form of FEATURE.
> @@ -832,7 +832,7 @@ Example: a struct with conditional feature 
> 'allow-negative-numbers'
>  { 'struct': 'TestType',
>    'data': { 'number': 'int' },
>    'features': [ { 'name': 'allow-negative-numbers',
> -                  'if': 'defined(IFCOND)' } ] }
> +                  'if': 'IFCOND' } ] }
>  
>  Please note that you are responsible to ensure that the C code will
>  compile with an arbitrary combination of conditions, since the

At this point in your series, the documentation does not yet reflect the
code changes you've made.  You now add another change together with a
doc update.  Now the docs match *no* version of the code, past, present,
or future.  I find this confusing.  Swap the last two patches?

How do you feel about updating documentation before the code?

[...]




reply via email to

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