1. 18 2月, 2019 2 次提交
  2. 25 10月, 2016 1 次提交
  3. 06 7月, 2016 1 次提交
    • E
      qapi: Add new clone visitor · a15fcc3c
      Eric Blake 提交于
      We have a couple places in the code base that want to deep-clone
      one QAPI object into another, and they were resorting to serializing
      the struct out to QObject then reparsing it.  A much more efficient
      version can be done by adding a new clone visitor.
      
      Since cloning is still relatively uncommon, expose the use of the
      new visitor via a QAPI_CLONE() macro that takes care of type-punning
      the underlying function pointer, rather than generating lots of
      unused functions for types that won't be cloned.  And yes, we're
      relying on the compiler treating all pointers equally, even though
      a strict C program cannot portably do so - but we're not the first
      one in the qemu code base to expect it to work (hello, glib!).
      
      The choice of adding a fourth visitor type deserves some explanation.
      On the surface, the clone visitor is mostly an input visitor (it
      takes arbitrary input - in this case, another QAPI object - and
      creates a new QAPI object during the course of the visit).  But
      ever since commit da72ab0 consolidated enum visits based on the
      visitor type, using VISITOR_INPUT would cause us to run
      visit_type_str(), even though for cloning there is nothing to do
      (we just copy the enum value across, without regards to its mapping
      to strings).   Also, since our input happens to be a QAPI object,
      we can also satisfy the internal checks for VISITOR_OUTPUT.  So in
      the end, I settled with a new VISITOR_CLONE, and chose its value
      such that many internal checks can use 'v->type & mask', sticking
      to 'v->type == value' where the difference matters.
      
      Note that we can only clone objects (including alternates) and lists,
      not built-ins or enums.  The visitor core hides integer width from
      the actual visitor (since commit 04e070d2), and as long as that's the
      case, we can't clone top-level integers.  Then again, those can
      always be cloned by direct copy, since they are not objects with
      deep pointers, so it's no real loss.  And restricting cloning to
      just objects and lists is cleaner than restricting it to non-integers.
      As such, I documented that the clone visitor is for direct use only
      by code internal to QAPI, and should not be used on incomplete objects
      (other than a hack to work around the fact that we allow NULL in place
      of "" in visit_type_str() in other output visitors).  Note that as
      written, the clone visitor will never fail on a complete object.
      
      Scalars (including enums) not at the root of the clone copy just fine
      with no additional effort while visiting the scalar, by virtue of a
      g_memdup() each time we push another struct onto the stack.  Cloning
      a string requires deduplication of a pointer, which means it can also
      provide the guarantee of an input visitor of never producing NULL
      even when still accepting NULL in place of "" the way the QMP output
      visitor does.
      
      Cloning an 'any' type could be possible by incrementing the QObject
      refcnt, but it's not obvious whether that is better than implementing
      a QObject deep clone.  So for now, we document it as unsupported,
      and intentionally omit the .type_any() callback to let a developer
      know their usage needs implementation.
      
      Add testsuite coverage for several different clone situations, to
      ensure that the code is working.  I also tested that valgrind was
      happy with the test.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1465490926-28625-14-git-send-email-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      a15fcc3c
  4. 08 9月, 2014 1 次提交
  5. 23 6月, 2014 1 次提交
  6. 13 1月, 2013 1 次提交
  7. 30 10月, 2012 1 次提交
  8. 23 7月, 2012 1 次提交
    • L
      qapi: introduce OptsVisitor · eb7ee2cb
      Laszlo Ersek 提交于
      This visitor supports parsing
      
        -option [type=]discriminator[,optarg1=val1][,optarg2=val2][,...]
      
      style QemuOpts objects into "native" C structures. After defining the type
      tree in the qapi schema (see below), a root type traversal with this
      visitor linked to the underlying QemuOpts object will build the "native" C
      representation of the option.
      
      The type tree in the schema, corresponding to an option with a
      discriminator, must have the following structure:
      
        struct
          scalar member for non-discriminated optarg 1 [*]
          list for repeating non-discriminated optarg 2 [*]
            wrapper struct
              single scalar member
          union
            struct for discriminator case 1
              scalar member for optarg 3 [*]
              list for repeating optarg 4 [*]
                wrapper struct
                  single scalar member
              scalar member for optarg 5 [*]
            struct for discriminator case 2
              ...
      
      The "type" optarg name is fixed for the discriminator role. Its schema
      representation is "union of structures", and each discriminator value must
      correspond to a member name in the union.
      
      If the option takes no "type" descriminator, then the type subtree rooted
      at the union must be absent from the schema (including the union itself).
      
      Optarg values can be of scalar types str / bool / integers / size.
      
      Members marked with [*] may be defined as optional in the schema,
      describing an optional optarg.
      
      Repeating an optarg is supported; its schema representation must be "list
      of structure with single mandatory scalar member". If an optarg is not
      described as repeating in the schema (ie. it is defined as a scalar field
      instead of a list), its last occurrence will take effect. Ordering between
      differently named optargs is not preserved.
      
      A mandatory list (or an optional one which is reported to be available),
      corresponding to a repeating optarg, has at least one element after
      successful parsing.
      
      v1->v2:
      - Update opts_type_size() prototype to uint64_t.
      - Add opts_type_uint64() for options needing the full uint64_t range.
        (Internals could be extracted to "cutils.c".)
      - Allow negative values in opts_type_int().
      - Rebase to nested Makefiles.
      
      v2->v3:
      - Factor opts_visitor_insert() out of opts_start_struct() and call it
        separately for opts_root->id if there's any.
      - Don't require non-negative values in opts_type_int()'s error message.
      - g_malloc0() may return NULL for zero-sized requests. Support empty
        structures by requesting 1 byte for them instead.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      eb7ee2cb
  9. 07 6月, 2012 1 次提交