1. 06 5月, 2015 23 次提交
    • E
      qapi: Merge UserDefTwo and UserDefNested in tests · b6fcf32d
      Eric Blake 提交于
      In the testsuite, UserDefTwo and UserDefNested were identical
      structs other than the member names.  Reduce code duplication by
      having just one type, and choose names that also favor reuse.
      This will also make it easier for a later patch to get rid of
      inline nested types in QAPI.  When touching code related to
      allocations, convert g_malloc0(sizeof(Type)) to the more typesafe
      g_new0(Type, 1).
      
      Ensure that 'make check-qapi-schema check-unit' still passes.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      b6fcf32d
    • E
      qapi: Use 'struct' instead of 'type' in schema · 895a2a80
      Eric Blake 提交于
      Referring to "type" as both a meta-type (built-in, enum, union,
      alternate, or struct) and a specific type (the name that the
      schema uses for declaring structs) is confusing.  Do the bulk of
      the conversion to "struct" in qapi schema, with a fairly
      mechanical:
      
      for f in `find -name '*.json'; do sed -i "s/'type'/'struct'/"; done
      
      followed by manually filtering out the places where we have a
      'type' embedded in 'data'.  Then tweak a couple of tests whose
      output changes slightly due to longer lines.
      
      I also verified that the generated files for QMP and QGA (such
      as qmp-commands.h) are the same before and after, as assurance
      that I didn't leave in any accidental member name changes.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      895a2a80
    • E
      qapi: Prefer 'struct' over 'type' in generator · fd41dd4e
      Eric Blake 提交于
      Referring to "type" as both a meta-type (built-in, enum, union,
      alternate, or struct) and a specific type (the name that the
      schema uses for declaring structs) is confusing.  The confusion
      is only made worse by the fact that the generator mostly already
      refers to struct even when dealing with expr['type'].  This
      commit changes the generator to consistently refer to it as
      struct everywhere, plus a single back-compat tweak that allows
      accepting the existing .json files as-is, so that the meat of
      this change is separate from the mindless churn of that change.
      
      Fix the testsuite fallout for error messages that change, and
      in some cases, become more legible.  Improve comments to better
      match our intentions where a struct (rather than any complex
      type) is required.  Note that in some cases, an error message
      now refers to 'struct' while the schema still refers to 'type';
      that will be cleaned up in the later commit to the schema.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      fd41dd4e
    • 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: Whitelist commands that don't return dictionary · 10d4d997
      Eric Blake 提交于
      ...or an array of dictionaries.  Although we have to cater to
      existing commands, returning a non-dictionary means the command
      is not extensible (no new name/value pairs can be added if more
      information must be returned in parallel).  By making the
      whitelist explicit, any new command that falls foul of this
      practice will have to be self-documenting, which will encourage
      developers to either justify the action or rework the design to
      use a dictionary after all.
      
      It's a little bit sloppy that we share a single whitelist among
      three clients (it's too permissive for each).  If this is a
      problem, a future patch could tighten things by having the
      generator take the whitelist as an argument (as in
      scripts/qapi-commands.py --legacy-returns=...), or by having
      the generator output C code that requires explicit use of the
      whitelist (as in:
       #ifndef FROBNICATE_LEGACY_RETURN_OK
       # error Command 'frobnicate' should return a dictionary
       #endif
      then having the callers define appropriate macros).  But until
      we need such fine-grained separation (if ever), this patch does
      the job just fine.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      10d4d997
    • E
      qapi: Require valid names · c9e0a798
      Eric Blake 提交于
      Previous commits demonstrated that the generator overlooked various
      bad naming situations:
      - types, commands, and events need a valid name
      - enum members must be valid names, when combined with prefix
      - union and alternate branches cannot be marked optional
      
      Valid upstream names match [a-zA-Z][a-zA-Z0-9_-]*; valid downstream
      names match __[a-zA-Z][a-zA-Z0-9._-]*.  Enumerations match the
      weaker [a-zA-Z0-9._-]+ (in part thanks to QKeyCode picking an enum
      that starts with a digit, which we can't change now due to
      backwards compatibility).  Rather than call out three separate
      regex, this patch just uses a broader combination that allows both
      upstream and downstream names, as well as a small hack that
      realizes that any enum name is merely a suffix to an already valid
      name prefix (that is, any enum name is valid if prepending _ fits
      the normal rules).
      
      We could reject new enumeration names beginning with a digit by
      whitelisting existing exceptions.  We could also be stricter
      about the distinction between upstream names (no leading
      underscore, no use of dot) and downstream (mandatory leading
      double underscore), but it is probably not worth the bother.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      c9e0a798
    • E
      qapi: More rigourous checking of types · dd883c6f
      Eric Blake 提交于
      Now that we know every expression is valid with regards to
      its keys, we can add further tests that those keys refer to
      valid types.  With this patch, all uses of a type (the 'data':
      of command, type, union, alternate, and event; the 'returns':
      of command; the 'base': of type and union) must resolve to an
      appropriate subset of metatypes  declared by the current qapi
      parse; this includes recursing into each member of a data
      dictionary.  Dealing with '**' and nested anonymous structs
      will be done in later patches.
      
      Update the testsuite to match improved output.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      dd883c6f
    • E
      qapi: Add some type check tests · 0d8b9fb5
      Eric Blake 提交于
      Demonstrate that the qapi generator silently parses confusing
      types, which may cause other errors later on. Later patches
      will update the expected results as the generator is made stricter.
      
      Most of the new tests focus on blatant errors.  But
      returns-whitelist is a case where we have historically allowed
      returning something other than a JSON object from particular
      commands; we have to keep that behavior to avoid breaking clients,
      but it would be nicer to avoid adding such commands in the future,
      because any return that is not an (array of) object cannot be
      easily extended if future qemu wants to return additional
      information.  The QMP protocol already documents that clients
      should ignore unknown dictionary keys, but does not require
      clients to have to handle more than one type of JSON object.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      0d8b9fb5
    • 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
    • F
      qapi: Allow true, false and null in schema json · e53188ad
      Fam Zheng 提交于
      In the near term, we will use it for a sensible-looking
      'gen':false inside command declarations, instead of the
      current ugly 'gen':'no'.
      
      In the long term, it will allow conversion from shorthand
      with defaults mentioned only in side-band documentation:
       'data':{'*flag':'bool', '*string':'str'}
      into an explicit default value documentation, as in:
       'data':{'flag':{'type':'bool', 'optional':true, 'default':true},
               'string':{'type':'str', 'optional':true, 'default':null}}
      
      We still don't parse integer values (also necessary before
      we can allow explicit defaults), but that can come in a later
      series.
      
      Update the testsuite to match an improved error message.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      e53188ad
    • E
      qapi: Better error messages for duplicated expressions · 4dc2e690
      Eric Blake 提交于
      The previous commit demonstrated that the generator overlooked
      duplicate expressions:
      - a complex type or command reusing a built-in type name
      - redeclaration of a type name, whether by the same or different
      metatype
      - redeclaration of a command or event
      - collision of a type with implicit 'Kind' enum for a union
      - collision with an implicit MAX enum constant
      
      Since the c_type() function in the generator treats all names
      as being in the same namespace, this patch adds a global array
      to track all known names and their source, to prevent collisions
      before it can cause further problems.  While valid .json files
      won't trigger any of these cases, we might as well be nicer to
      developers that make a typo while trying to add new QAPI code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      4dc2e690
    • E
      qapi: Add tests of redefined expressions · cfdd5bca
      Eric Blake 提交于
      Demonstrate that the qapi generator doesn't deal very well with
      redefined expressions.  At the parse level, they are silently
      accepted; and while the testsuite just stops at parsing, I've
      further tested that many of them cause generator crashes or
      invalid C code if they were appended to qapi-schema-test.json.
      A later patch will tighten things up and adjust the testsuite
      to match.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cfdd5bca
    • E
      qapi: Better error messages for bad expressions · 0545f6b8
      Eric Blake 提交于
      The previous commit demonstrated that the generator overlooked some
      fairly basic broken expressions:
      - missing metataype
      - metatype key has a non-string value
      - unknown key in relation to the metatype
      - conflicting metatype (this patch treats the second metatype as an
      unknown key of the first key visited, which is not necessarily the
      first key the user typed)
      
      Add check_keys to cover these situations, and update testcases to
      match.  A couple other tests (enum-missing-data, indented-expr) had
      to change since the validation added here occurs so early.
      Conversely, changes to ident-with-escape results show that we still
      have problems where our handling of escape sequences differs from
      true JSON, which will matter down the road if we allow arbitrary
      default string values for optional parameters (but for now is not
      too bad, as we currently can avoid unicode escaping as we don't
      need to represent anything beyond C identifier material).
      
      While valid .json files won't trigger any of these cases, we might
      as well be nicer to developers that make a typo while trying to add
      new QAPI code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      0545f6b8
    • E
      qapi: Add some expr tests · 9050c65b
      Eric Blake 提交于
      Demonstrate that the qapi generator doesn't deal well with
      expressions that aren't up to par. Later patches will improve
      the expected results as the generator is made stricter.  Only
      a few of the the added tests actually behave sanely at
      rejecting obvious problems or demonstrating success.
      
      Note that in some cases, we reject bad QAPI merely because our
      pseudo-JSON parser does not yet know how to parse numbers.  This
      series does not address that, but when a later series adds support
      for numeric defaults of integer fields, the testsuite will ensure
      that we don't lose the error (and hopefully that the error
      message quality is improved).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      9050c65b
    • E
      qapi: Use 'alternate' to replace anonymous union · ab916fad
      Eric Blake 提交于
      Previous patches have led up to the point where I create the
      new meta-type "'alternate':'Foo'".  See the previous patches
      for documentation; I intentionally split as much work into
      earlier patches to minimize the size of this patch, but a lot
      of it is churn due to testsuite fallout after updating to the
      new type.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ab916fad
    • E
      qapi: Rename anonymous union type in test · ab045267
      Eric Blake 提交于
      Reduce churn in the future patch that replaces anonymous unions
      with a new metatype 'alternate' by changing 'AnonUnion' to
      'Alternate'.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ab045267
    • E
      qapi: Segregate anonymous unions into alternates in generator · 811d04fd
      Eric Blake 提交于
      Special-casing 'discriminator == {}' for handling anonymous unions
      is getting awkward; since this particular type is not always a
      dictionary on the wire, it is easier to treat it as a completely
      different class of type, "alternate", so that if a type is listed
      in the union_types array, we know it is not an anonymous union.
      
      This patch just further segregates union handling, to make sure that
      anonymous unions are not stored in union_types, and splitting up
      check_union() into separate functions.  A future patch will change
      the qapi grammar, and having the segregation already in place will
      make it easier to deal with the distinct meta-type.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      811d04fd
    • E
      qapi: Tighten checking of unions · 44bd1276
      Eric Blake 提交于
      Previous commits demonstrated that the generator had several
      flaws with less-than-perfect unions:
      - a simple union that listed the same branch twice (or two variant
      names that map to the same C enumerator, including the implicit
      MAX sentinel) ended up generating invalid C code
      - an anonymous union that listed two branches with the same qtype
      ended up generating invalid C code
      - the generator crashed on anonymous union attempts to use an
      array type
      - the generator was silently ignoring a base type for anonymous
      unions
      - the generator allowed unknown types or nested anonymous unions
      as a branch in an anonymous union
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      44bd1276
    • E
      qapi: Forbid base without discriminator in unions · a8d4a2e4
      Eric Blake 提交于
      None of the existing QMP or QGA interfaces uses a union with a
      base type but no discriminator; it is easier to avoid this in the
      generator to save room for other future extensions more likely to
      be useful.  An earlier commit added a union-base-no-discriminator
      test to ensure that we eventually give a decent error message;
      likewise, removing UserDefUnion outright is okay, because we moved
      all the tests we wish to keep into the tests of the simple union
      UserDefNativeListUnion in the previous commit.  Now is the time to
      actually forbid simple union with base, and remove the last
      vestiges from the testsuite.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      a8d4a2e4
    • E
      qapi: Add some union tests · 3d0c4829
      Eric Blake 提交于
      Demonstrate that the qapi generator doesn't deal well with unions
      that aren't up to par. Later patches will update the expected
      reseults as the generator is made stricter.  A few tests work
      as planned, but most show poor or missing error messages.
      
      Of particular note, qapi-code-gen.txt documents 'base' only for
      flat unions, but the tests here demonstrate that we currently allow
      a 'base' to a simple union, although it is exercised only in the
      testsuite.  Later patches will remove this undocumented feature, to
      give us more flexibility in adding other future extensions to union
      types.  For example, one possible extension is the idea of a
      type-safe simple enum, where added fields tie the discriminator to
      a user-defined enum type rather than creating an implicit enum from
      the names in 'data'.  But adding such safety on top of a simple
      enum with a base type could look ambiguous with a flat enum;
      besides, the documentation also mentions how any simple union can
      be represented by an equivalent flat union.  So it will be simpler
      to just outlaw support for something we aren't using.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      3d0c4829
    • E
      qapi: Better error messages for bad enums · cf393590
      Eric Blake 提交于
      The previous commit demonstrated that the generator had several
      flaws with less-than-perfect enums:
      - an enum that listed the same string twice (or two variant
      strings that map to the same C enumerator) ended up generating
      an invalid C enum
      - because the generator adds a _MAX terminator to each enum,
      the use of an enum member 'max' can also cause this clash
      - if an enum omits 'data', the generator left a python stack
      trace rather than a graceful message
      - an enum that used a non-array 'data' was silently accepted by
      the parser
      - an enum that used non-string members in the 'data' member
      was silently accepted by the parser
      
      Add check_enum to cover these situations, and update testcases
      to match.  While valid .json files won't trigger any of these
      cases, we might as well be nicer to developers that make a typo
      while trying to add new QAPI code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cf393590
    • E
      qapi: Add some enum tests · ad11dbb9
      Eric Blake 提交于
      Demonstrate that the qapi generator doesn't deal well with enums
      that aren't up to par. Later patches will update the expected
      results as the generator is made stricter.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ad11dbb9
    • E
      qapi: Fix generation of 'size' builtin type · cb17f79e
      Eric Blake 提交于
      We were missing the 'size' builtin type (which means that QAPI using
      [ 'size' ] would fail to compile).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cb17f79e
  2. 27 9月, 2014 1 次提交
  3. 27 6月, 2014 1 次提交
  4. 23 6月, 2014 2 次提交
  5. 16 5月, 2014 1 次提交
  6. 09 5月, 2014 3 次提交
  7. 11 3月, 2014 5 次提交
  8. 04 3月, 2014 4 次提交