1. 25 Oct, 2016 1 commit
    • Daniel P. Berrange's avatar
      qdict: implement a qdict_crumple method for un-flattening a dict · 603476c2
      Daniel P. Berrange authored
      The qdict_flatten() method will take a dict whose elements are
      further nested dicts/lists and flatten them by concatenating
      The qdict_crumple() method aims to do the reverse, taking a flat
      qdict, and turning it into a set of nested dicts/lists. It will
      apply nesting based on the key name, with a '.' indicating a
      new level in the hierarchy. If the keys in the nested structure
      are all numeric, it will create a list, otherwise it will create
      a dict.
      If the keys are a mixture of numeric and non-numeric, or the
      numeric keys are not in strictly ascending order, an error will
      be reported.
      As an example, a flat dict containing
         'foo.0.bar': 'one',
         'foo.0.wizz': '1',
         'foo.1.bar': 'two',
         'foo.1.wizz': '2'
      will get turned into a dict with one element 'foo' whose
      value is a list. The list elements will each in turn be
         'foo': [
           { 'bar': 'one', 'wizz': '1' },
           { 'bar': 'two', 'wizz': '2' }
      If the key is intended to contain a literal '.', then it must
      be escaped as '..'. ie a flat dict
           'foo..bar': 'wizz',
           'bar.foo..bar': 'eek',
           'bar.hello': 'world'
      Will end up as
           'foo.bar': 'wizz',
           'bar': {
              'foo.bar': 'eek',
              'hello': 'world'
      The intent of this function is that it allows a set of QemuOpts
      to be turned into a nested data structure that mirrors the nesting
      used when the same object is defined over QMP.
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1475246744-29302-3-git-send-email-berrange@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      [Parameter recursive dropped along with its tests; whitespace style
      touched up]
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
  2. 12 Jul, 2016 1 commit
  3. 06 Jul, 2016 1 commit
  4. 30 Jun, 2016 2 commits
    • Eric Blake's avatar
      qobject: Correct JSON lexer grammar comments · ff5394ad
      Eric Blake authored
      Fix the regex comments describing what we parse as JSON.  No change
      to the lexer itself, just to the comments:
      - The "" and '' string construction was missing alternation between
      different escape sequences
      - The construction for numbers forgot to handle optional leading '-'
      - The construction for numbers was grouped incorrectly so that it
      didn't permit '0.1'
      - The construction for numbers forgot to mark the exponent as optional
      - No mention that our '' string and "\'" are JSON extensions
      - No mention of our %d and related extensions when constructing JSON
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1465526889-8339-2-git-send-email-eblake@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      [Eric's regexp simplification squashed in]
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
    • Eric Blake's avatar
      json-streamer: Don't leak tokens on incomplete parse · ba4dba54
      Eric Blake authored
      Valgrind complained about a number of leaks in
      ==12657==    definitely lost: 17,247 bytes in 1,234 blocks
      All of which had the same root cause: on an incomplete parse,
      we were abandoning the token queue without cleaning up the
      allocated data within each queue element.  Introduced in
      commit 95385fe9, when we switched from QList (which recursively
      frees contents) to g_queue (which does not).
      We don't yet require glib 2.32 with its g_queue_free_full(),
      so open-code it instead.
      CC: qemu-stable@nongnu.org
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1463608012-12760-1-git-send-email-eblake@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
  5. 20 Jun, 2016 1 commit
    • Eduardo Habkost's avatar
      coccinelle: Remove unnecessary variables for function return value · 9be38598
      Eduardo Habkost authored
      Use Coccinelle script to replace 'ret = E; return ret' with
      'return E'. The script will do the substitution only when the
      function return type and variable type are the same.
      Manual fixups:
      * audio/audio.c: coding style of "read (...)" and "write (...)"
      * block/qcow2-cluster.c: wrap line to make it shorter
      * block/qcow2-refcount.c: change indentation of wrapped line
      * target-tricore/op_helper.c: fix coding style of
      * target-mips/dsp_helper.c: reverted changes because I don't
        want to argue about checkpatch.pl
      * ui/qemu-pixman.c: fix line indentation
      * block/rbd.c: restore blank line between declarations and
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1465855078-19435-4-git-send-email-ehabkost@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      [Unused Coccinelle rule name dropped along with a redundant comment;
      whitespace touched up in block/qcow2-cluster.c; stale commit message
      paragraph deleted]
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
  6. 18 May, 2016 1 commit
  7. 22 Mar, 2016 2 commits
    • Veronia Bahaa's avatar
      util: move declarations out of qemu-common.h · f348b6d1
      Veronia Bahaa authored
      Move declarations out of qemu-common.h for functions declared in
      utils/ files: e.g. include/qemu/path.h for utils/path.c.
      Move inline functions out of qemu-common.h and into new files (e.g.
      Signed-off-by: 's avatarVeronia Bahaa <veroniabahaa@gmail.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
    • Markus Armbruster's avatar
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster authored
      Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the
      Error typedef.  Since then, we've moved to include qemu/osdep.h
      everywhere.  Its file comment explains: "To avoid getting into
      possible circular include dependencies, this file should not include
      any other QEMU headers, with the exceptions of config-host.h,
      compiler.h, os-posix.h and os-win32.h, all of which are doing a
      similar job to this file and are under similar constraints."
      qapi/error.h doesn't do a similar job, and it doesn't adhere to
      similar constraints: it includes qapi-types.h.  That's in excess of
      100KiB of crap most .c files don't actually need.
      Add the typedef to qemu/typedefs.h, and include that instead of
      qapi/error.h.  Include qapi/error.h in .c files that need it and don't
      get it now.  Include qapi-types.h in qom/object.h for uint16List.
      Update scripts/clean-includes accordingly.  Update it further to match
      reality: replace config.h by config-target.h, add sysemu/os-posix.h,
      sysemu/os-win32.h.  Update the list of includes in the qemu/osdep.h
      comment quoted above similarly.
      This reduces the number of objects depending on qapi/error.h from "all
      of them" to less than a third.  Unfortunately, the number depending on
      qapi-types.h shrinks only a little.  More work is needed for that one.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  8. 08 Feb, 2016 1 commit
    • Eric Blake's avatar
      qobject: Document more shortcomings in our number handling · 6e8e5cb9
      Eric Blake authored
      We've already documented that our JSON parsing is locale dependent;
      but we should also document that our JSON output has the same
      problem.  Additionally, JSON requires finite values (you have to
      upgrade to JSON5 to get support for Inf or NaN), and our output
      truncates floating point numbers to the point of losing significant
      precision that could cause the receiver to read a different value.
      Sadly, this series is not going to be the one that addresses these
      Fix some trailing whitespace I noticed in the vicinity.
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1454075341-13658-2-git-send-email-eblake@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
  9. 04 Feb, 2016 1 commit
  10. 17 Dec, 2015 3 commits
    • Eric Blake's avatar
      qapi: Convert QType into QAPI built-in enum type · 7264f5c5
      Eric Blake authored
      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: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-4-git-send-email-eblake@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
    • Eric Blake's avatar
      qobject: Rename qtype_code to QType · 1310a3d3
      Eric Blake authored
      The name QType matches our CODING_STYLE conventions for type names
      in CamelCase.  It also matches the fact that we are already naming
      all the enum members with a prefix of QTYPE, not QTYPE_CODE.  And
      doing the rename will also make it easier for the next patch to use
      QAPI for providing the enum, which also wants CamelCase type names.
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-3-git-send-email-eblake@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
    • Eric Blake's avatar
      qobject: Simplify QObject · 55e1819c
      Eric Blake authored
      The QObject hierarchy is small enough, and unlikely to grow further
      (since we only use it to map to JSON and already cover all JSON
      types), that we can simplify things by not tracking a separate
      vtable, but just inline the code element of the vtable QType
      directly into QObject (renamed to type), and track a separate array
      of destroy functions.  We can drop qnull_destroy_obj() in the
      The remaining QObject subclasses must export their destructor.
      This also has the nice benefit of moving the typename 'QType'
      out of the way, so that the next patch can repurpose it for a
      nicer name for 'qtype_code'.
      The various objects are still the same size (so no change in cache
      line pressure), but now have less indirection (although I didn't
      bother benchmarking to see if there is a noticeable speedup, as
      we don't have hard evidence that this was in a performance hotspot
      in the first place).
      A future patch could drop the refcnt size to 32 bits for a smaller
      struct on 64-bit architectures, if desired (we have limits on the
      largest JSON that we are willing to parse, and will probably never
      need to take full advantage of a 64-bit refcnt).
      Suggested-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-2-git-send-email-eblake@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
  11. 26 Nov, 2015 11 commits
  12. 29 Oct, 2015 5 commits
  13. 22 Jun, 2015 4 commits
  14. 12 Jun, 2015 2 commits
  15. 11 May, 2015 3 commits
    • Eric Blake's avatar
      json-parser: Accept 'null' in QMP · e549e716
      Eric Blake authored
      We document that in QMP, the client may send any json-value
      for the optional "id" key, and then return that same value
      on reply (both success and failures, insofar as the failure
      happened after parsing the id).  [Note that the output may
      not be identical to the input, as whitespace may change and
      since we may reorder keys within a json-object, but that this
      still constitutes the same json-value].  However, we were not
      handling the JSON literal null, which counts as a json-value
      per RFC 7159.
      Also, down the road, given the QAPI schema of {'*foo':'str'} or
      {'*foo':'ComplexType'}, we could decide to allow the QMP client
      to pass { "foo":null } instead of the current representation of
      { } where omitting the key is the only way to get at the default
      NULL value.  Such a change might be useful for argument
      introspection (if a type in older qemu lacks 'foo' altogether,
      then an explicit "foo":null probe will force an easily
      distinguished error message for whether the optional "foo" key
      is even understood in newer qemu).  And if we add default values
      to optional arguments, allowing an explicit null would be
      required for getting a NULL value associated with an optional
      string that has a non-null default.  But all that can come at a
      later day.
      The 'check-unit' testsuite is enhanced to test that parsing
      produces the same object as explicitly requesting a reference
      to the special qnull object.  In addition, I tested with:
      $ ./x86_64-softmmu/qemu-system-x86_64 -qmp stdio -nodefaults
      {"QMP": {"version": {"qemu": {"micro": 91, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}}
      {"return": {}, "id": null}
      {"return": {}, "id": {"a": null, "b": [1, null]}}
      {"timestamp": {"seconds": 1427742379, "microseconds": 423128}, "event": "SHUTDOWN"}
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
    • Markus Armbruster's avatar
      qobject: Add a special null QObject · 481b002c
      Markus Armbruster authored
      I'm going to fix the JSON parser to recognize null.  The obvious
      representation of JSON null as (QObject *)NULL doesn't work, because
      the parser already uses it as an error value.  Perhaps we should
      change it to free NULL for null, but that's more than I can do right
      now.  Create a special null QObject instead.
      The existing QDict, QList, and QString all represent something that
      is a pointer in C and could therefore be associated with NULL.  But
      right now, all three of these sub-types are always non-null once
      created, so the new null sentinel object is intentionally unrelated
      to them.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
    • Markus Armbruster's avatar
      qobject: Clean up around qtype_code · a7c31816
      Markus Armbruster authored
      QTYPE_NONE is a sentinel value.  No QObject has this type code.
      Document it properly.
      Fix dump_qobject() to abort() on QTYPE_NONE, just like for any other
      invalid type code.
      Fix to_json() to abort() on all invalid type codes, not just
      Clean up Property member qtype's type: it's a qtype_code.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
  16. 10 Dec, 2014 1 commit