Referring to "type" as both a meta-type (built-in, enum, union,
alternte, or struct) and a specific type (the name that the
schema uses for declaring structs) is confusing. Finish up the
conversion to using "struct" in qapi schema by coverting all
users, then remove the hack in the generator that
We have more than one qapi schema in use by more than one protocol.
Add a new term 'Client JSON Protocol' for use throughout the
document, to avoid confusion on whether something refers only to
QMP and not QGA.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
v6: rebase to earlier
A future patch will be using a 'name':{dictionary} entry in the
QAPI schema to specify a default value for an optional argument
(see previous commit message for more details why); but existing
use of inline nested structs conflicts with that goal. This patch
fixes one of only two commands relying o
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
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 a
A future patch will be using a 'name':{dictionary} entry in the
QAPI schema to specify a default value for an optional argument
(see previous commit message for more details why); but existing
use of inline nested structs conflicts with that goal. This patch
fixes one of only two commands relying o
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 t
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' e
Referring to "type" as both a meta-type (built-in, enum, union,
alternte, or struct) and a specific type (the name that the
schema uses for declaring structs) is confusing. Now that the
generator accepts 'struct' as a synonym for 'type', update all
documentation to use saner wording.
Signed-off-b
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 v
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
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
The set of valid names includes [a-zA-Z_
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 behaves sanely at
rejecting obvious problems or demonstrating success.
Note t
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 th
Referring to "type" as both a meta-type (built-in, enum, union,
alternte, 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['
From: 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', '*s
...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
A future patch will be using a 'name':{dictionary} entry in the
QAPI schema to specify a default value for an optional argument
(see previous commit messages for more details why); but existing
use of inline nested structs conflicts with that goal. Now that
all commands have been changed to avoid i
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 bo
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
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
Go into more details about the various types of valid expressions
in a qapi schema, including tweaks to document fixes being done
later in the current patch series. Also fix some stale and missing
documentation in the QMP specification.
Signed-off-by: Eric Blake
---
v6: split copyright change
Reduce churn in the future patch that replaces anonymous unions
with a new metatype 'alternate' by changing 'AnonUnion' to
'Alternate'.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
v6: no change
---
tests/qapi-schema/qapi-schema-test.json | 2 +-
tests/qapi-schema/qapi-schema
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
The next patch will quit special-casing "'union':'Foo',
'discriminator':{}" and instead use "'alternate':'Foo'".
Separating docs from implementation makes it easier to focus
on wording without holding up code. In particular, making
alternate a separate type makes for a nice type hierarchy:
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 'b
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
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: Eric Blake
---
v6: add test enum-bad-name (everything else was R-b Markus, but the
new test means this still n
We want to eventually allow qapi defaults, by making:
'data':{'*flag':'bool'}
as shorthand for something like:
'data':{'flag':{'type':'bool', 'optional':true}}
so that the default can be specified:
'data':{'flag':{'type':'bool', 'optional':true, 'default':true}}
This series does not quite get u
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. A previous commit added a union-base-no-discriminator
test to ensure that we eventually give
Python 2 and Python 3 have a wild history of whether strings
default to ascii or unicode, where Python 3 requires checking
isinstance(foo, basestr) to cover all strings, but where that
code is not portable to Python 2. It's simpler to just state
that we don't care about Unicode strings, and to jus
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 i
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 enu
While our top-level COPYING with its GPLv2+ license applies to
any documentation file that omits explicit instructions, these
days it's better to be a good example of calling out our
intentions. Correct use of GPL requires the use of a copyright
statement, so I'm adding notice to two QAPI document
This patch widens the scope of a try block (with the attending
reindentation required by Python) in preparation for a future
patch adding more instances of QAPIExprError inside the block.
It's easier to separate indentation from semantic changes, so
this patch has no real behavior change.
Signed-o
There was some redundancy between builtin_types[] and
builtin_type_qtypes{}. Merge them into one.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
v6: split from 2/28
---
scripts/qapi-types.py | 10 +-
scripts/qapi-visit.py | 6 +++---
scripts/qapi.py | 8 +---
We were missing the 'size' builtin type (which means that QAPI using
[ 'size' ] would fail to compile).
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
v6: split from 2/28
---
scripts/qapi.py | 1 +
tests/qapi-schema/qapi-schema-test.json | 3 ++-
tests/qa
Ok, done. It's at https://github.com/cminyard/qemu on github. There
are two branches at the moment, stable-2.2-ipmi is based on the 2.2
release and will not rebase. master-ipmi-rebase will rebase on master
as it moves.
I haven't done extensive testing yet, and it has a few experimental
things,
On 04/04/2015 05:14 AM, Dirk Müller wrote:
> Therefore for any board that uses memory_region_init_ram directly,
> -mem-path is not supported.
>
> Fix this by replacing memory_region_init_ram with
> memory_region_allocate_system_memory.
>
> Cc: Richard Henderson
> Signed-off-by: Dirk Mueller
> -
> On 01 Apr 2015, at 16:18, Leon Alrae wrote:
>
> ... I would like to follow up with a clean up
> where we've got a semi-hosting specific structure rather than keep generating
> more semihosting_* variables.
I checked the differences between my fork and the master branch (SourceTree for
Mac is
Commit 0b183fc871:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.
Therefore for any board that
Commit 0b183fc871:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.
Therefore for any board that
Commit 0b183fc871:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.
Therefore for any board that
Commit 0b183fc871:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.
Therefore for any board that
From: Jan Kiszka
Probably a copy&paste bug. Fixing it helps identifying the device model
behind port 0x61.
Signed-off-by: Jan Kiszka
Reviewed-by: Gonglei
Signed-off-by: Michael Tokarev
---
hw/audio/pcspk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/audio/pcspk.c b
From: Greg Kurz
Signed-off-by: Greg Kurz
Acked-by: Jason Wang
Signed-off-by: Michael Tokarev
---
include/hw/virtio/vhost.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index d5593d1..8f04888 100644
--- a/include/hw/v
From: Stefan Weil
With a mask value of 0x0040, the result will never be 1.
This fixes a Coverity warning.
Signed-off-by: Stefan Weil
Signed-off-by: Michael Tokarev
---
target-tricore/op_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-tricore/op_helper.c
From: "Emilio G. Cota"
Signed-off-by: Emilio G. Cota
Reviewed-by: Paolo Bonzini
Signed-off-by: Michael Tokarev
---
target-i386/cpu.h | 2 --
translate-all.c | 4
2 files changed, 6 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 15db6d7..4ee12ca 100644
--- a/targ
Here's a very small trivial-patches pull request for the upcoming 2.3
release. There's nothing urgent here, so things can wait past 2.3,
but these things are also safe. Only one "questionable" code change
is the removal of TARGET_HAS_SMC macro, but it was applied long ago
(to -trivial) and it loo
From: Eric Blake
kvm_stat.{1,pod} started showing up as untracked files in my
directory, and I nearly accidentally merged them into a commit
with my usual habit of 'git add .'. Rather than spelling out
each such file, just ignore the entire pattern.
Signed-off-by: Eric Blake
Reviewed-by: Stefa
50 matches
Mail list logo
