Re: [PATCH v3 12/34] qapi: Add feature flags to remaining definitions

[Eric Blake]

On 3/17/20 12:46 AM, Markus Armbruster wrote:

> > > +++ b/tests/qapi-schema/doc-good.json
> > > @@ -53,10 +53,14 @@
> > >    # @Enum:
> > >    # @one: The _one_ {and only}
> > >    #
> > > +# Features:
> > > +# @enum-feat: Also _one_ {and only}
>     +#
>      # @two is undocumented
>      ##
>      { 'enum': 'Enum', 'data':
>        [ { 'name': 'one', 'if': 'defined(IFONE)' }, 'two' ],
>     +  'features': [ 'enum-feat' ],
>        'if': 'defined(IFCOND)' }
>
> > All our existing public features are a single word (matching naming
> > conventions elsewhere in QAPI).  Are we sure we want to allow feature
> > names that include whitespace?  Of course, the fact that our testsuite
> > covers it (even if we don't use it publically) means that we are sure
> > that our generator can handle it, regardless of whether we decide that
> > a separate patch should restrict feature names.  But I don't see it
> > holding up this patch.
>
> We definitely do not want to exempt feature names from the QAPI naming
> rules.
>
> The code enforces this.  If I change '-' to ' ' in 'features': [
> 'enum-feat' ], I get
>
>      doc-good.json:61: 'features' member 'enum feat' has an invalid name

Good. I was getting confused between the doc comment (which generally 
should have spaces, rather than being one word) and the feature name 
itself.  Sorry for the distraction.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org