qemu/tests/qapi-schema/qapi-schema-test.json

113 lines
3.5 KiB
JSON
Raw Normal View History

# *-*- Mode: Python -*-*
# for testing enums
{ 'enum': 'EnumOne',
'data': [ 'value1', 'value2', 'value3' ] }
{ 'struct': 'NestedEnumsOne',
'data': { 'enum1': 'EnumOne', '*enum2': 'EnumOne', 'enum3': 'EnumOne', '*enum4': 'EnumOne' } }
# for testing nested structs
{ 'struct': 'UserDefZero',
'data': { 'integer': 'int' } }
{ 'struct': 'UserDefOne',
'base': 'UserDefZero',
'data': { 'string': 'str', '*enum1': 'EnumOne' } }
qapi: Drop tests for inline nested structs 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: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-05-04 18:05:30 +03:00
{ 'struct': 'UserDefTwoDictDict',
'data': { 'userdef': 'UserDefOne', 'string': 'str' } }
{ 'struct': 'UserDefTwoDict',
'data': { 'string1': 'str',
'dict2': 'UserDefTwoDictDict',
'*dict3': 'UserDefTwoDictDict' } }
{ 'struct': 'UserDefTwo',
'data': { 'string0': 'str',
qapi: Drop tests for inline nested structs 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: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-05-04 18:05:30 +03:00
'dict1': 'UserDefTwoDict' } }
# for testing unions
{ 'struct': 'UserDefA',
'data': { 'boolean': 'bool' } }
{ 'struct': 'UserDefB',
'data': { 'integer': 'int' } }
{ 'struct': 'UserDefC',
'data': { 'string1': 'str', 'string2': 'str' } }
{ 'struct': 'UserDefUnionBase',
'data': { 'string': 'str', 'enum1': 'EnumOne' } }
{ 'union': 'UserDefFlatUnion',
'base': 'UserDefUnionBase',
'discriminator': 'enum1',
'data': { 'value1' : 'UserDefA', 'value2' : 'UserDefB', 'value3' : 'UserDefB' } }
# FIXME generated struct UserDefFlatUnion has members for direct base
# UserDefOne, but lacks members for indirect base UserDefZero
# this variant of UserDefFlatUnion defaults to a union that uses fields with
# allocated types to test corner cases in the cleanup/dealloc visitor
{ 'union': 'UserDefFlatUnion2',
'base': 'UserDefUnionBase',
'discriminator': 'enum1',
'data': { 'value1' : 'UserDefC', 'value2' : 'UserDefB', 'value3' : 'UserDefA' } }
{ 'alternate': 'UserDefAlternate',
'data': { 'uda': 'UserDefA', 's': 'str', 'i': 'int' } }
# for testing native lists
{ 'union': 'UserDefNativeListUnion',
'data': { 'integer': ['int'],
's8': ['int8'],
's16': ['int16'],
's32': ['int32'],
's64': ['int64'],
'u8': ['uint8'],
'u16': ['uint16'],
'u32': ['uint32'],
'u64': ['uint64'],
'number': ['number'],
'boolean': ['bool'],
'string': ['str'],
'sizes': ['size'] } }
# testing commands
{ 'command': 'user_def_cmd', 'data': {} }
{ 'command': 'user_def_cmd1', 'data': {'ud1a': 'UserDefOne'} }
{ 'command': 'user_def_cmd2',
'data': {'ud1a': 'UserDefOne', '*ud1b': 'UserDefOne'},
'returns': 'UserDefTwo' }
{ 'command': 'user_def_cmd3', 'data': {'a': 'int', '*b': 'int' },
'returns': 'int' }
# For testing integer range flattening in opts-visitor. The following schema
# corresponds to the option format:
#
# -userdef i64=3-6,i64=-5--1,u64=2,u16=1,u16=7-12
#
# For simplicity, this example doesn't use [type=]discriminator nor optargs
# specific to discriminator values.
{ 'struct': 'UserDefOptions',
'data': {
'*i64' : [ 'int' ],
'*u64' : [ 'uint64' ],
'*u16' : [ 'uint16' ],
'*i64x': 'int' ,
'*u64x': 'uint64' } }
# testing event
{ 'struct': 'EventStructOne',
'data': { 'struct1': 'UserDefOne', 'string': 'str', '*enum2': 'EnumOne' } }
{ 'event': 'EVENT_A' }
{ 'event': 'EVENT_B',
'data': { } }
{ 'event': 'EVENT_C',
'data': { '*a': 'int', '*b': 'UserDefOne', 'c': 'str' } }
{ 'event': 'EVENT_D',
'data': { 'a' : 'EventStructOne', 'b' : 'str', '*c': 'str', '*enum3': 'EnumOne' } }
# test that we correctly compile downstream extensions
{ 'enum': '__org.qemu_x-Enum', 'data': [ '__org.qemu_x-value' ] }