Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The discriminator for anonymous unions is the data type. This allows to
have a union type that allows both of these:

    { 'file': 'my_existing_block_device_id' }
    { 'file': { 'filename': '/tmp/mydisk.qcow2', 'read-only': true } }

Unions like this are specified in the schema with an empty dict as
discriminator. For this example you could take:

    { 'union': 'BlockRef',
      'discriminator': {},
      'data': { 'definition': 'BlockOptions',
                'reference': 'str' } }
    { 'type': 'ExampleObject',
      'data: { 'file': 'BlockRef' } }
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Instead of the rather verbose syntax that distinguishes base and
subclass fields...

  { "type": "file",
    "read-only": true,
    "data": {
        "filename": "test"
    } }

...we can now have both in the same namespace, allowing a more direct
mapping of the command line, and moving fields between the common base
and subclasses without breaking the API:

  { "driver": "file",
    "read-only": true,
    "filename": "test" }
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The new 'base' key in a union definition refers to a struct type, which
is inlined into the union definition and can represent fields common to
all kinds.

For example the following schema definition...

    { 'type': 'BlockOptionsBase', 'data': { 'read-only': 'bool' } }

    { 'union': 'BlockOptions',
      'base': 'BlockOptionsBase',
      'data': {
          'raw': 'BlockOptionsRaw'
          'qcow2': 'BlockOptionsQcow2'
      } }

...would result in this generated C struct:

    struct BlockOptions
    {
        BlockOptionsKind kind;
        union {
            void *data;
            BlockOptionsRaw * raw;
            BlockOptionsQcow2 * qcow2;
        };
        bool read_only;
    };
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.

On 32-bit architectures, this can lead to situations where 'next' field
offset in GenericList does not correspond to the 'next' field in the
types that we cast to GenericList when using the visit_next_list()
interface, causing issues when we attempt to traverse linked list
structures of these types.

To fix this, pad the 'value' field of GenericList and other
schema-defined/native *List types out to 64-bits.

This is less memory-efficient for 32-bit architectures, but allows us to
continue to rely on list-handling interfaces that target GenericList to
simply visitor implementations.

In the future we can improve efficiency by defaulting to using native C
array backends to handle list of non-pointer types, which would be more
memory efficient in itself and allow us to roll back this change.
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Teach type generators about native types so they can generate the
appropriate linked list types.
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Needed to prevent build breakage when CPUState becomes a child of
DeviceState.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
[ehabkost: include <stdbool.h> too]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Enum values are always preceded by the uppercase name of the enum, so
they do not conflict with reserved words.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Currently, if we define an 'enum' and use it in one command's
data, list struct for enum could not be generated, but it's
used in qmp function.

For example: KeyCodesList could not be generated.
>>> qapi-schema.json:
{ 'enum': 'KeyCodes',
  'data': [ 'shift', 'alt' ... ] }
{ 'command': 'sendkey',
  'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }

>>> qmp-command.h:
void qmp_sendkey(KeyCodesList * keys, bool has_hold_time, int64_t
hold_time, Error **errp);

This patch lets qapi generate list struct and visit_list for enum.
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Next commit will introduce enum strings in camel case.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>

An enum like GenericError in the schema, should generate
GENERIC_ERROR and not GENERICERROR.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>

qapi-types.h needs only qemu-common.h. Including qapi-types-core.h
causes problems when qerror.h or error.h includes qapi-types.h.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>

Signed-off-by: NFederico Simoncelli <fsimonce@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Acked-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

The fixes to qapi code generation had multiple bugs:
- the Null class used to drop output was missing some methods
- in some scripts it was never instantiated, leading to a None return,
  which is missing even more methods
- the --source and --header options were swapped

Luckily, all those bugs were hidden by a makefile bug which caused the
old behaviour (with the race) to be invoked.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Make's multiple output syntax

  x.c x.h: x.template
       gen < x.template

actually invokes the command once for x.c and once for x.h (with differing $@
in each invocation).  During a parallel build, the two commands may be invoked
in parallel; this opens up a race, where the second invocation trashes a file
supposedly produced during the first, and now in use by a dependent command.

The various qapi code generators are susceptible to this; fix by making them
generate just one file per invocation.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

It's the last value in the enum and is very useful for the C
implementation.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Otherwise if we have something like 'foo-bar' in the schema,
it will be generated as 'foo_bar' in the string lookup table.

c_var() is good for C variables, but not for enum strings.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

To get the ball rolling merging QAPI, this patch introduces a "middle mode" to
the code generator.  In middle mode, the code generator generates marshalling
functions that are compatible with the current QMP server.  We absolutely need
to replace the current QMP server in order to support proper asynchronous
commands but using a middle mode provides a middle-ground that lets us start
converting commands in tree.

Note that all of the commands have been converted already in my glib branch.
Middle mode only exists until we finish merging them from my branch into the
main tree.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

This is the code generator for qapi types. It will generation the
following files:

  $(prefix)qapi-types.h - C types corresponding to types defined in
                          the schema you pass in
  $(prefix)qapi-types.c - Cleanup functions for the above C types

The $(prefix) is used to as a namespace to keep the generated code from
one schema/code-generation separated from others so code and be
generated from multiple schemas with clobbering previously created code.
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@gmail.com>