1. 16 1月, 2017 1 次提交
    • M
      qapi: add qapi2texi script · 3313b612
      Marc-André Lureau 提交于
      As the name suggests, the qapi2texi script converts JSON QAPI
      description into a texi file suitable for different target
      formats (info/man/txt/pdf/html...).
      
      It parses the following kind of blocks:
      
      Free-form:
      
        ##
        # = Section
        # == Subsection
        #
        # Some text foo with *emphasis*
        # 1. with a list
        # 2. like that
        #
        # And some code:
        # | $ echo foo
        # | -> do this
        # | <- get that
        #
        ##
      
      Symbol description:
      
        ##
        # @symbol:
        #
        # Symbol body ditto ergo sum. Foo bar
        # baz ding.
        #
        # @param1: the frob to frobnicate
        # @param2: #optional how hard to frobnicate
        #
        # Returns: the frobnicated frob.
        #          If frob isn't frobnicatable, GenericError.
        #
        # Since: version
        # Notes: notes, comments can have
        #        - itemized list
        #        - like this
        #
        # Example:
        #
        # -> { "execute": "quit" }
        # <- { "return": {} }
        #
        ##
      
      That's roughly following the following EBNF grammar:
      
      api_comment = "##\n" comment "##\n"
      comment = freeform_comment | symbol_comment
      freeform_comment = { "# " text "\n" | "#\n" }
      symbol_comment = "# @" name ":\n" { member | tag_section | freeform_comment }
      member = "# @" name ':' [ text ] "\n" freeform_comment
      tag_section = "# " ( "Returns:", "Since:", "Note:", "Notes:", "Example:", "Examples:" ) [ text ]  "\n" freeform_comment
      text = free text with markup
      
      Note that the grammar is ambiguous: a line "# @foo:\n" can be parsed
      both as freeform_comment and as symbol_comment.  The actual parser
      recognizes symbol_comment.
      
      See docs/qapi-code-gen.txt for more details.
      
      Deficiencies and limitations:
      - the generated QMP documentation includes internal types
      - union type support is lacking
      - type information is lacking in generated documentation
      - doc comment error message positions are imprecise, they point
        to the beginning of the comment.
      - a few minor issues, all marked TODO/FIXME in the code
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20170113144135.5150-16-marcandre.lureau@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      [test-qapi.py tweaked to avoid trailing empty lines in .out]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      3313b612
  2. 06 5月, 2015 2 次提交
    • E
      qapi: More rigorous checking for type safety bypass · 2cbf0992
      Eric Blake 提交于
      Now that we have a way to validate every type, we can also be
      stricter about enforcing that callers that want to bypass
      type safety in generated code.  Prior to this patch, it didn't
      matter what value was associated with the key 'gen', but it
      looked odd that 'gen':'yes' could result in bypassing the
      generated code.  These changes also enforce the changes made
      earlier in the series for documentation and consolidation of
      using '**' as the wildcard type, as well as 'gen':false as the
      canonical spelling for requesting type bypass.
      
      Note that 'gen':false is a one-way switch away from the default;
      we do not support 'gen':true (similar for 'success-response').
      In practice, this doesn't matter.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      2cbf0992
    • E
      qapi: Unify type bypass and add tests · d708cdbe
      Eric Blake 提交于
      For a few QMP commands, we are forced to pass an arbitrary type
      without tracking it properly in QAPI.  Among the existing clients,
      this unnamed type was spelled 'dict', 'visitor', and '**'; this
      patch standardizes on '**', matching the documentation changes
      earlier in the series.
      
      Meanwhile, for the 'gen' key, we have been ignoring the value,
      although the schema consistently used "'no'" ('success-response'
      was hard-coded to checking for 'no').  But now that we can support
      a literal "false" in the schema, we might as well use that rather
      than ignoring the value or special-casing a random string.  Note
      that these are one-way switches (use of 'gen':true is not the same
      as omitting 'gen'). Also, the use of '**' requires 'gen':false,
      but the use of 'gen':false does not mandate the use of '**'.
      
      There is no difference to the generated code.  Add some tests on
      what we'd like to guarantee, although it will take later patches
      to clean up test results and actually enforce the use of a bool
      parameter.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      d708cdbe