1. 02 11月, 2015 1 次提交
    • E
      qapi: Unbox base members · ddf21908
      Eric Blake 提交于
      Rather than storing a base class as a pointer to a box, just
      store the fields of that base class in the same order, so that
      a child struct can be directly cast to its parent.  This gives
      less malloc overhead, less pointer dereferencing, and even less
      generated code.  Compare to the earlier commit 1e6c1616 "qapi:
      Generate a nicer struct for flat unions" (although that patch
      had fewer places to change, as less of qemu was directly using
      qapi structs for flat unions).  It also allows us to turn on
      automatic type-safe wrappers for upcasting to the base class
      of a struct.
      
      Changes to the generated code look like this in qapi-types.h:
      
      | struct SpiceChannel {
      |-    SpiceBasicInfo *base;
      |+    /* Members inherited from SpiceBasicInfo: */
      |+    char *host;
      |+    char *port;
      |+    NetworkAddressFamily family;
      |+    /* Own members: */
      |     int64_t connection_id;
      
      as well as additional upcast functions like qapi_SpiceChannel_base().
      Meanwhile, changes to qapi-visit.c look like:
      
      | static void visit_type_SpiceChannel_fields(Visitor *v, SpiceChannel **obj, Error **errp)
      | {
      |     Error *err = NULL;
      |
      |-    visit_type_implicit_SpiceBasicInfo(v, &(*obj)->base, &err);
      |+    visit_type_SpiceBasicInfo_fields(v, (SpiceBasicInfo **)obj, &err);
      |     if (err) {
      
      (the cast is necessary, since our upcast wrappers only deal with a
      single pointer, not pointer-to-pointer); plus the wholesale
      elimination of some now-unused visit_type_implicit_FOO() functions.
      
      Without boxing, the corner case of one empty struct having
      another empty struct as its base type now requires inserting a
      dummy member (previously, the 'Base *base' member sufficed).
      
      And now that we no longer consume a 'base' member in the generated
      C struct, we can delete the former negative struct-base-clash-base
      test.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1445898903-12082-11-git-send-email-eblake@redhat.com>
      [Commit message tweaked slightly]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ddf21908
  2. 21 9月, 2015 2 次提交
  3. 04 9月, 2015 1 次提交
  4. 22 6月, 2015 2 次提交
  5. 06 5月, 2015 5 次提交
    • E
      qapi: Drop tests for inline nested structs · 6446a592
      Eric Blake 提交于
      A future patch will be using a 'name':{dictionary} entry in the
      QAPI schema to specify a default value for an optional argument;
      but existing use of inline nested structs conflicts with that goal.
      
      More precisely, a definition in the QAPI schema associates a name
      with a set of properties:
      
      Example 1: { 'struct': 'Foo', 'data': { MEMBERS... } }
      associates the global name 'Foo' with properties (meta-type struct)
      and MEMBERS...
      
      Example 2: 'mumble': TYPE
      within MEMBERS... above associates 'mumble' with properties (type
      TYPE) and (optional false) within type Foo
      
      The syntax of example 1 is extensible; if we need another property,
      we add another name/value pair to the dictionary (such as
      'base':TYPE).  The syntax of example 2 is not extensible, because
      the right hand side can only be a type.
      
      We have used name encoding to add a property: "'*mumble': 'int'"
      associates 'mumble' with (type int) and (optional true).  Nice,
      but doesn't scale.  So the solution is to change our existing uses
      to be syntactic sugar to an extensible form:
      
         NAME: TYPE   --> NAME:  { 'type': TYPE, 'optional': false }
         *ONAME: TYPE --> ONAME: { 'type': TYPE, 'optional': true }
      
      This patch fixes the testsuite to avoid inline nested types, by
      breaking the nesting into explicit types; it means that the type
      is now boxed instead of unboxed in C code, but makes no difference
      on the wire (and if desired, a later patch could change the
      generator to not do so much boxing in C).  When touching code to
      add new allocations, also convert existing allocations to
      consistently prefer typesafe g_new0 over g_malloc0 when a type
      name is involved.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      6446a592
    • 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: 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: 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: Clean up test coverage of simple unions · 805017b7
      Eric Blake 提交于
      The tests of UserDefNativeListUnion serve to validate code
      generation of simple unions without a base type, except that it
      did not have full coverage in the strict test.  The next commits
      will remove tests and support for simple unions with a base type,
      so there is no real loss at repurposing that test here as
      opposed to churn of adding a new test then deleting the old one.
      
      Fix some indentation and long lines while at it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      805017b7
  6. 28 5月, 2014 1 次提交
  7. 16 5月, 2014 2 次提交
    • M
      qapi: Replace uncommon use of the error API by the common one · 297a3646
      Markus Armbruster 提交于
      We commonly use the error API like this:
      
          err = NULL;
          foo(..., &err);
          if (err) {
              goto out;
          }
          bar(..., &err);
      
      Every error source is checked separately.  The second function is only
      called when the first one succeeds.  Both functions are free to pass
      their argument to error_set().  Because error_set() asserts no error
      has been set, this effectively means they must not be called with an
      error set.
      
      The qapi-generated code uses the error API differently:
      
          // *errp was initialized to NULL somewhere up the call chain
          frob(..., errp);
          gnat(..., errp);
      
      Errors accumulate in *errp: first error wins, subsequent errors get
      dropped.  To make this work, the second function does nothing when
      called with an error set.  Requires non-null errp, or else the second
      function can't see the first one fail.
      
      This usage has also bled into visitor tests, and two device model
      object property getters rtc_get_date() and balloon_stats_get_all().
      
      With the "accumulate" technique, you need fewer error checks in
      callers, and buy that with an error check in every callee.  Can be
      nice.
      
      However, mixing the two techniques is confusing.  You can't use the
      "accumulate" technique with functions designed for the "check
      separately" technique.  You can use the "check separately" technique
      with functions designed for the "accumulate" technique, but then
      error_set() can't catch you setting an error more than once.
      
      Standardize on the "check separately" technique for now, because it's
      overwhelmingly prevalent.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      297a3646
    • M
      tests: Don't call visit_end_struct() after visit_start_struct() fails · cdaec380
      Markus Armbruster 提交于
      When visit_start_struct() fails, visit_end_struct() must not be
      called.  Three out of four visit_type_TestStruct() call it anyway.  As
      far as I can tell, visit_start_struct() doesn't actually fail there.
      Fix them anyway.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      cdaec380
  8. 09 5月, 2014 1 次提交
  9. 11 3月, 2014 1 次提交
  10. 04 3月, 2014 4 次提交
  11. 18 2月, 2014 1 次提交
  12. 27 7月, 2013 1 次提交
  13. 30 5月, 2013 1 次提交
    • M
      qapi: pad GenericList value fields to 64 bits · a678e26c
      Michael Roth 提交于
      With the introduction of native list types, we now have types such as
      int64List where the 'value' field is not a pointer, but the actual
      64-bit value.
      
      On 32-bit architectures, this can lead to situations where 'next' field
      offset in GenericList does not correspond to the 'next' field in the
      types that we cast to GenericList when using the visit_next_list()
      interface, causing issues when we attempt to traverse linked list
      structures of these types.
      
      To fix this, pad the 'value' field of GenericList and other
      schema-defined/native *List types out to 64-bits.
      
      This is less memory-efficient for 32-bit architectures, but allows us to
      continue to rely on list-handling interfaces that target GenericList to
      simply visitor implementations.
      
      In the future we can improve efficiency by defaulting to using native C
      array backends to handle list of non-pointer types, which would be more
      memory efficient in itself and allow us to roll back this change.
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      a678e26c
  14. 23 5月, 2013 1 次提交
  15. 19 12月, 2012 2 次提交
  16. 30 3月, 2012 1 次提交
  17. 27 3月, 2012 1 次提交
  18. 12 3月, 2012 1 次提交
  19. 07 3月, 2012 1 次提交
  20. 06 12月, 2011 1 次提交