1. 14 12月, 2018 1 次提交
  2. 03 3月, 2018 2 次提交
  3. 20 6月, 2017 1 次提交
  4. 16 3月, 2017 1 次提交
  5. 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
  6. 18 3月, 2016 1 次提交
    • E
      qapi: Adjust names of implicit types · 7599697c
      Eric Blake 提交于
      The original choice of ':obj-' as the prefix for implicit types
      made it obvious that we weren't going to clash with any user-defined
      names, which cannot contain ':'.  But now we want to create structs
      for implicit types, to get rid of special cases in the generators,
      and our use of ':' in implicit names needs a tweak to produce valid
      C code.
      
      We could transliterate ':' to '_', except that C99 mandates that
      "identifiers that begin with an underscore are always reserved for
      use as identifiers with file scope in both the ordinary and tag name
      spaces".  So it's time to change our naming convention: we can
      instead use the 'q_' prefix that we reserved for ourselves back in
      commit 9fb081e0.  Technically, since we aren't planning on exposing
      the empty type in generated code, we could keep the name ':empty',
      but renaming it to 'q_empty' makes the check for startswith('q_')
      cover all implicit types, whether or not code is generated for them.
      
      As long as we don't declare 'empty' or 'obj' ticklish, it shouldn't
      clash with c_name() prepending 'q_' to the user's ticklish names.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1458254921-17042-5-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      7599697c
  7. 17 12月, 2015 1 次提交
    • E
      qapi: Convert QType into QAPI built-in enum type · 7264f5c5
      Eric Blake 提交于
      What's more meta than using qapi to define qapi? :)
      
      Convert QType into a full-fledged[*] builtin qapi enum type, so
      that a subsequent patch can then use it as the discriminator
      type of qapi alternate types.  Fortunately, the judicious use of
      'prefix' in the qapi definition avoids churn to the spelling of
      the enum constants.
      
      To avoid circular definitions, we have to flip the order of
      inclusion between "qobject.h" vs. "qapi-types.h".  Back in commit
      28770e05, we had the latter include the former, so that we could
      use 'QObject *' for our implementation of 'any'.  But that usage
      also works with only a forward declaration, whereas the
      definition of QObject requires QType to be a complete type.
      
      [*] The type has to be builtin, rather than declared in
      qapi/common.json, because we want to use it for alternates even
      when common.json is not included. But since it is the first
      builtin enum type, we have to add special cases to qapi-types
      and qapi-visit to only emit definitions once, even when two
      qapi files are being compiled into the same binary (the way we
      already handled builtin list types like 'intList').  We may
      need to revisit how multiple qapi files share common types,
      but that's a project for another day.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-4-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      7264f5c5
  8. 21 9月, 2015 2 次提交
    • M
      qapi: New QMP command query-qmp-schema for QMP introspection · 39a18158
      Markus Armbruster 提交于
      qapi/introspect.json defines the introspection schema.  It's designed
      for QMP introspection, but should do for similar uses, such as QGA.
      
      The introspection schema does not reflect all the rules and
      restrictions that apply to QAPI schemata.  A valid QAPI schema has an
      introspection value conforming to the introspection schema, but the
      converse is not true.
      
      Introspection lowers away a number of schema details, and makes
      implicit things explicit:
      
      * The built-in types are declared with their JSON type.
      
        All integer types are mapped to 'int', because how many bits we use
        internally is an implementation detail.  It could be pressed into
        external interface service as very approximate range information,
        but that's a bad idea.  If we need range information, we better do
        it properly.
      
      * Implicit type definitions are made explicit, and given
        auto-generated names:
      
        - Array types, named by appending "List" to the name of their
          element type, like in generated C.
      
        - The enumeration types implicitly defined by simple union types,
          named by appending "Kind" to the name of their simple union type,
          like in generated C.
      
        - Types that don't occur in generated C.  Their names start with ':'
          so they don't clash with the user's names.
      
      * All type references are by name.
      
      * The struct and union types are generalized into an object type.
      
      * Base types are flattened.
      
      * Commands take a single argument and return a single result.
      
        Dictionary argument or list result is an implicit type definition.
      
        The empty object type is used when a command takes no arguments or
        produces no results.
      
        The argument is always of object type, but the introspection schema
        doesn't reflect that.
      
        The 'gen': false directive is omitted as implementation detail.
      
        The 'success-response' directive is omitted as well for now, even
        though it's not an implementation detail, because it's not used by
        QMP.
      
      * Events carry a single data value.
      
        Implicit type definition and empty object type use, just like for
        commands.
      
        The value is of object type, but the introspection schema doesn't
        reflect that.
      
      * Types not used by commands or events are omitted.
      
        Indirect use counts as use.
      
      * Optional members have a default, which can only be null right now
      
        Instead of a mandatory "optional" flag, we have an optional default.
        No default means mandatory, default null means optional without
        default value.  Non-null is available for optional with default
        (possible future extension).
      
      * Clients should *not* look up types by name, because type names are
        not ABI.  Look up the command or event you're interested in, then
        follow the references.
      
        TODO Should we hide the type names to eliminate the temptation?
      
      New generator scripts/qapi-introspect.py computes an introspection
      value for its input, and generates a C variable holding it.
      
      It can generate awfully long lines.  Marked TODO.
      
      A new test-qmp-input-visitor test case feeds its result for both
      tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
      QmpInputVisitor to verify it actually conforms to the schema.
      
      New QMP command query-qmp-schema takes its return value from that
      variable.  Its reply is some 85KiBytes for me right now.
      
      If this turns out to be too much, we have a couple of options:
      
      * We can use shorter names in the JSON.  Not the QMP style.
      
      * Optionally return the sub-schema for commands and events given as
        arguments.
      
        Right now qmp_query_schema() sends the string literal computed by
        qmp-introspect.py.  To compute sub-schema at run time, we'd have to
        duplicate parts of qapi-introspect.py in C.  Unattractive.
      
      * Let clients cache the output of query-qmp-schema.
      
        It changes only on QEMU upgrades, i.e. rarely.  Provide a command
        query-qmp-schema-hash.  Clients can have a cache indexed by hash,
        and re-query the schema only when they don't have it cached.  Even
        simpler: put the hash in the QMP greeting.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      39a18158
    • M
      tests/qapi-schema: Convert test harness to QAPISchemaVisitor · 156402e5
      Markus Armbruster 提交于
      The old code prints the result of parsing (list of expression
      dictionaries), and partial results of semantic analysis (list of enum
      dictionaries, list of struct dictionaries).
      
      The new code prints a trace of a schema visit, i.e. what the back-ends
      are going to use.  Built-in and array types are omitted, because
      they're boring.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      156402e5
  9. 11 3月, 2014 1 次提交
  10. 29 7月, 2013 3 次提交