qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 4cf2d8: QJSON: Use OBJECT_CHECK


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 4cf2d8: QJSON: Use OBJECT_CHECK
Date: Tue, 12 May 2015 03:00:07 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 4cf2d837340589155acfda993c51e66eb5800416
      
https://github.com/qemu/qemu/commit/4cf2d837340589155acfda993c51e66eb5800416
  Author: Eduardo Habkost <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M qjson.c

  Log Message:
  -----------
  QJSON: Use OBJECT_CHECK

The QJSON code used casts to (QJSON*) directly, instead of OBJECT_CHECK.
There were even some functions using object_dynamic_cast() calls
followed by assert(), which is exactly what OBJECT_CHECK does (by
calling object_dynamic_cast_assert()).

Signed-off-by: Eduardo Habkost <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: a7c31816288a8f20fc387d69d441413e7a8c9ff1
      
https://github.com/qemu/qemu/commit/a7c31816288a8f20fc387d69d441413e7a8c9ff1
  Author: Markus Armbruster <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M block/qapi.c
    M include/hw/qdev-core.h
    M include/qapi/qmp/qobject.h
    M qobject/qjson.c

  Log Message:
  -----------
  qobject: Clean up around qtype_code

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
QTYPE_MAX.

Clean up Property member qtype's type: it's a qtype_code.

Signed-off-by: Markus Armbruster <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: 481b002cc81ed7fc7b06e32e9d4d495d81739d14
      
https://github.com/qemu/qemu/commit/481b002cc81ed7fc7b06e32e9d4d495d81739d14
  Author: Markus Armbruster <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M include/qapi/qmp/qobject.h
    M qobject/Makefile.objs
    M qobject/qjson.c
    A qobject/qnull.c

  Log Message:
  -----------
  qobject: Add a special null QObject

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: Markus Armbruster <address@hidden>
Signed-off-by: Eric Blake <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: e549e7161f37416ff66971d77d021d30057045ca
      
https://github.com/qemu/qemu/commit/e549e7161f37416ff66971d77d021d30057045ca
  Author: Eric Blake <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M qobject/json-parser.c
    M tests/check-qjson.c

  Log Message:
  -----------
  json-parser: Accept 'null' in QMP

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": []}}
{"execute":"qmp_capabilities","id":null}
{"return": {}, "id": null}
{"id":{"a":null,"b":[1,null]},"execute":"quit"}
{"return": {}, "id": {"a": null, "b": [1, null]}}
{"timestamp": {"seconds": 1427742379, "microseconds": 423128}, "event": 
"SHUTDOWN"}

Signed-off-by: Eric Blake <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: 9740618cd2a0ed85b9c1648f05f3066f525f4b2e
      
https://github.com/qemu/qemu/commit/9740618cd2a0ed85b9c1648f05f3066f525f4b2e
  Author: Luiz Capitulino <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: New maintainer for QMP and QAPI

Markus is taking over maintership of QMP and the QAPI from
me. Markus has always been a great reviewer and contributor
to those subsystems. In the last few months he's also doing
pull requests that are a lot more relevant than the ones I
was able to do. So, this is a natural move.

I'm still the maintainer of HMP and QObjects, but I'm
looking for someone to take over those too.

PS: This commit also fixes the file listing for the QMP
    entry.

Signed-off-by: Luiz Capitulino <address@hidden>
Reviewed-by: Michael Roth <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>


  Commit: a7430a0badc59bd6295936e06c1869e8fe32649d
      
https://github.com/qemu/qemu/commit/a7430a0badc59bd6295936e06c1869e8fe32649d
  Author: John Snow <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M scripts/qmp/qmp-shell

  Log Message:
  -----------
  scripts: qmp-shell: refactor helpers

Refactor the qmp-shell command line processing function
into two components. This will be used to allow sub-expressions,
which will assist us in adding transactional support to qmp-shell.

Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Tested-by: Kashyap Chamarthy <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: 6092c3ecc4bdafee5bf07061be78a4a2cc5a5088
      
https://github.com/qemu/qemu/commit/6092c3ecc4bdafee5bf07061be78a4a2cc5a5088
  Author: John Snow <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M scripts/qmp/qmp-shell

  Log Message:
  -----------
  scripts: qmp-shell: Expand support for QMP expressions

This includes support for [] expressions, single-quotes in
QMP expressions (which is not strictly a part of JSON), and
the ability to use "True", "False" and "None" literals instead
of JSON's equivalent true, false, and null literals.

qmp-shell currently allows you to describe values as
JSON expressions:
key={"key":{"key2":"val"}}

But it does not currently support arrays, which are needed
for serializing and deserializing transactions:
key=[{"type":"drive-backup","data":{...}}]

qmp-shell also only currently accepts doubly quoted strings
as-per JSON spec, but QMP allows single quotes.

Lastly, python allows you to utilize "True" or "False" as
boolean literals, but JSON expects "true" or "false". Expand
qmp-shell to allow the user to type either, converting to the
correct type.

As a consequence of the above, the key=val parsing is also improved
to give better error messages if a key=val token is not provided.

CAVEAT: The parser is still extremely rudimentary and does not
expect to find spaces in {} nor [] expressions. This patch does
not improve this functionality.

Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Tested-by: Kashyap Chamarthy <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: 30bd6815efbaf5bae70885feac9a35e149e2f1ad
      
https://github.com/qemu/qemu/commit/30bd6815efbaf5bae70885feac9a35e149e2f1ad
  Author: John Snow <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M scripts/qmp/qmp-shell

  Log Message:
  -----------
  scripts: qmp-shell: add transaction subshell

Add a special processing mode to craft transactions.

By entering "transaction(" the shell will enter a special
mode where each subsequent command will be saved as a transaction
instead of executed as an individual command.

The transaction can be submitted by entering ")" on a line by itself.

Examples:

Separate lines:

(QEMU) transaction(
TRANS> block-dirty-bitmap-add node=drive0 name=bitmap1
TRANS> block-dirty-bitmap-clear node=drive0 name=bitmap0
TRANS> )

With a transaction action included on the first line:

(QEMU) transaction( block-dirty-bitmap-add node=drive0 name=bitmap2
TRANS> block-dirty-bitmap-add node=drive0 name=bitmap3
TRANS> )

As a one-liner, with just one transaction action:

(QEMU) transaction( block-dirty-bitmap-add node=drive0 name=bitmap0 )

As a side-effect of this patch, blank lines are now parsed as no-ops,
regardless of which shell mode you are in.

Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Tested-by: Kashyap Chamarthy <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: 1ceca07e48ead0dd2e41576c81d40e6a91cafefd
      
https://github.com/qemu/qemu/commit/1ceca07e48ead0dd2e41576c81d40e6a91cafefd
  Author: John Snow <address@hidden>
  Date:   2015-05-11 (Mon, 11 May 2015)

  Changed paths:
    M scripts/qmp/qmp-shell

  Log Message:
  -----------
  scripts: qmp-shell: Add verbose flag

Add a verbose flag that shows the QMP command that was
constructed, to allow for later copy/pasting, reference,
debugging, etc.

The QMP is converted from a Python literal to JSON first,
to ensure that it is viable input to the actual QMP parser.

As a side-effect, this JSON output will helpfully show all
the necessary conversions that were performed on the input,
illustrating that "True" was transformed back into "true",
literal values are now escaped with "" instead of '', and so on.

Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Tested-by: Kashyap Chamarthy <address@hidden>
Signed-off-by: Luiz Capitulino <address@hidden>


  Commit: 704eb1c09963149db4a3407d5ba173ba2a9244bb
      
https://github.com/qemu/qemu/commit/704eb1c09963149db4a3407d5ba173ba2a9244bb
  Author: Peter Maydell <address@hidden>
  Date:   2015-05-12 (Tue, 12 May 2015)

  Changed paths:
    M MAINTAINERS
    M block/qapi.c
    M include/hw/qdev-core.h
    M include/qapi/qmp/qobject.h
    M qjson.c
    M qobject/Makefile.objs
    M qobject/json-parser.c
    M qobject/qjson.c
    A qobject/qnull.c
    M scripts/qmp/qmp-shell
    M tests/check-qjson.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/qmp-unstable/tags/for-upstream' into 
staging

QMP pull request

# gpg: Signature made Mon May 11 14:15:19 2015 BST using RSA key ID E24ED5A7
# gpg: Good signature from "Luiz Capitulino <address@hidden>"

* remotes/qmp-unstable/tags/for-upstream:
  scripts: qmp-shell: Add verbose flag
  scripts: qmp-shell: add transaction subshell
  scripts: qmp-shell: Expand support for QMP expressions
  scripts: qmp-shell: refactor helpers
  MAINTAINERS: New maintainer for QMP and QAPI
  json-parser: Accept 'null' in QMP
  qobject: Add a special null QObject
  qobject: Clean up around qtype_code
  QJSON: Use OBJECT_CHECK

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/0403b0f539f4...704eb1c09963

reply via email to

[Prev in Thread] Current Thread [Next in Thread]