summaryrefslogtreecommitdiff
path: root/scripts/qapi
AgeCommit message (Collapse)Author
2019-06-12qapi: Simplify how QAPIDoc implements its state machineMarkus Armbruster
QAPIDoc uses a state machine to for processing of documentation lines. Its state is encoded as an enum QAPIDoc._state (well, as enum-like class actually, thanks to our infatuation with Python 2). All we ever do with the state is calling the state's function to process a line of documentation. The enum values effectively serve as handles for the functions. Eliminate the rather wordy indirection: store the function to call in QAPIDoc._append_line. Update and improve comments. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190606153803.5278-8-armbru@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> [Commit message typo fixed]
2019-06-12qapi: Allow documentation for featuresKevin Wolf
Features will be documented in a new part introduced by a "Features:" line, after arguments and before named sections. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20190606153803.5278-6-armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-06-12qapi: Disentangle QAPIDoc codeKevin Wolf
Documentation comments follow a certain structure: First, we have a text with a general description (called QAPIDoc.body). After this, descriptions of the arguments follow. Finally, we have a part that contains various named sections. The code doesn't show this structure, but just checks various attributes that indicate indirectly which part is being processed, so it happens to do the right set of things in the right phase. This is hard to follow, and adding support for documentation of features would be even harder. This patch restructures the code so that the three parts are clearly separated. The code becomes a bit longer, but easier to follow. The resulting output remains unchanged. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20190606153803.5278-5-armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-06-12qapi: Add feature flags to struct typesKevin Wolf
Sometimes, the behaviour of QEMU changes without a change in the QMP syntax (usually by allowing values or operations that previously resulted in an error). QMP clients may still need to know whether they can rely on the changed behavior. Let's add feature flags to the QAPI schema language, so that we can make such changes visible with schema introspection. An example for a schema definition using feature flags looks like this: { 'struct': 'TestType', 'data': { 'number': 'int' }, 'features': [ 'allow-negative-numbers' ] } Introspection information then looks like this: { "name": "TestType", "meta-type": "object", "members": [ { "name": "number", "type": "int" } ], "features": [ "allow-negative-numbers" ] } This patch implements feature flags only for struct types. We'll implement them more widely as needed. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20190606153803.5278-2-armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-06-12Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
2019-03-05qapi: Fix array first used in a different moduleMarkus Armbruster
We generally put implicitly defined types in whatever module triggered their definition. This is wrong for array types, as the included test case demonstrates. Let's have a closer look at it. Type 'Status' is defined sub-sub-module.json. Array type ['Status'] occurs in main module qapi-schema-test.json and in include/sub-module.json. The main module's use is first, so the array type gets put into the main module. The generated C headers define StatusList in qapi-types.h. But include/qapi-types-sub-module.h uses it without including qapi-types.h. Oops. To fix that, put the array type into its element type's module. Now StatusList gets generated into qapi-types-sub-module.h, which all its users include. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190301154051.23317-8-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2019-03-05qapi: Fix code generation for sub-modules in other directoriesMarkus Armbruster
The #include directives to pull in sub-modules use file names relative to the main module. Works only when all modules are in the same directory, or the main module's output directory is in the compiler's include path. Use relative file names instead. The dummy variable we generate to avoid empty .o files has an invalid name for sub-modules in other directories. Fix that. Both messed up in commit 252dc3105fc "qapi: Generate separate .h, .c for each module". Escaped testing because tests/qapi-schema-test.json doesn't cover sub-modules in other directories, only tests/qapi-schema/include-relpath.json does, and we generate and compile C code only for the former, not the latter. Fold the latter into the former. This would have caught the mistakes fixed in this commit. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190301154051.23317-5-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2019-03-05qapi: Pass file name to QAPIGen constructor instead of methodsMarkus Armbruster
Not much of an improvement now, but the next commit will profit. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190301154051.23317-4-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2019-02-18Revert "qapi-events: add 'if' condition to implicit event enum"Markus Armbruster
This reverts commit 7bd263490590ee6fcf34ecb6203437e22f6e5a9c. The commit applied the events' conditions to the members of enum QAPIEvent. Awkward, because it renders QAPIEvent unusable in target-independent code as soon as we make an event target-dependent. Reverting this has the following effects: * ui/vnc.c can remain target independent. * monitor_qapi_event_conf[] doesn't have to muck around with #ifdef. * query-events again doesn't reflect conditionals. I'm going to deprecate it in favor of query-qmp-schema. Another option would be to split target-dependent parts off enum QAPIEvent into a target-dependent enum. Doesn't seem worthwhile right now. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-17-armbru@redhat.com>
2019-02-18qapi: Generate QAPIEvent stuff into separate filesMarkus Armbruster
Having to include qapi-events.h just for QAPIEvent is suboptimal, but quite tolerable now. It'll become problematic when we have events conditional on the target, because then qapi-events.h won't be usable from target-independent code anymore. Avoid that by generating it into separate files. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-6-armbru@redhat.com>
2019-02-18qapi: Prepare for system modules other than 'builtin'Markus Armbruster
The next commit wants to generate qapi-emit-events.{c.h}. To enable that, extend QAPISchemaModularCVisitor to support additional "system modules", i.e. modules that don't correspond to a (user-defined) QAPI schema module. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-5-armbru@redhat.com>
2019-02-18qapi: Clean up modular built-in code generation a bitMarkus Armbruster
We neglect to call .visit_module() for the special module we use for built-ins. Harmless, but clean it up anyway. The tests/qapi-schema/*.out now show the built-in module as 'module None'. Subclasses of QAPISchemaModularCVisitor need to ._add_module() this special module to enable code generation for built-ins. When this hasn't been done, QAPISchemaModularCVisitor.visit_module() does nothing for the special module. That looks like built-ins could accidentally be generated into the wrong module when a subclass neglects to call ._add_module(). Can't happen, because built-ins are all visited before any other module. But that's non-obvious. Switch off code generation explicitly. Rename QAPISchemaModularCVisitor._begin_module() to ._begin_user_module(). New QAPISchemaModularCVisitor._is_builtin_module(), for clarity. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-4-armbru@redhat.com>
2019-01-24qapi: Eliminate indirection through qmp_event_get_func_emit()Markus Armbruster
The qapi_event_send_FOO() functions emit events like this: QMPEventFuncEmit emit; emit = qmp_event_get_func_emit(); if (!emit) { return; } qmp = qmp_event_build_dict("FOO"); [put event arguments into @qmp...] emit(QAPI_EVENT_FOO, qmp); The value of qmp_event_get_func_emit() depends only on the program: * In qemu-system-FOO, it's always monitor_qapi_event_queue. * In tests/test-qmp-event, it's always event_test_emit. * In all other programs, it's always null. This is exactly the kind of dependence the linker is supposed to resolve; we don't actually need an indirection. Note that things would fall apart if we linked more than one QAPI schema into a single program: each set of qapi_event_send_FOO() uses its own event enumeration, yet they share a single emit function. Which takes the event enumeration as an argument. Which one if there's more than one? More seriously: how does this work even now? qemu-system-FOO wants QAPIEvent, and passes a function taking that to qmp_event_set_func_emit(). test-qmp-event wants test_QAPIEvent, and passes a function taking that to qmp_event_set_func_emit(). It works by type trickery, of course: typedef void (*QMPEventFuncEmit)(unsigned event, QDict *dict); void qmp_event_set_func_emit(QMPEventFuncEmit emit); QMPEventFuncEmit qmp_event_get_func_emit(void); We use unsigned instead of the enumeration type. Relies on both enumerations boiling down to unsigned, which happens to be true for the compilers we use. Clean this up as follows: * Generate qapi_event_send_FOO() that call PREFIX_qapi_event_emit() instead of the value of qmp_event_set_func_emit(). * Generate a prototype for PREFIX_qapi_event_emit() into qapi-events.h. * PREFIX_ is empty for qapi/qapi-schema.json, and test_ for tests/qapi-schema/qapi-schema-test.json. It's qga_ for qga/qapi-schema.json, and doc-good- for tests/qapi-schema/doc-good.json, but those don't define any events. * Rename monitor_qapi_event_queue() to qapi_event_emit() instead of passing it to qmp_event_set_func_emit(). This takes care of qemu-system-FOO. * Rename event_test_emit() to test_qapi_event_emit() instead of passing it to qmp_event_set_func_emit(). This takes care of tests/test-qmp-event. * Add a qapi_event_emit() that does nothing to stubs/monitor.c. This takes care of all other programs that link code emitting QMP events. * Drop qmp_event_set_func_emit(), qmp_event_get_func_emit(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181218182234.28876-3-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [Commit message typos fixed]
2018-12-18qapi: fix flat union on uncovered branches conditionalsMarc-André Lureau
Default branches variant should use the member conditional. This fixes compilation with --disable-replication. Fixes: 335d10cd8e2c3bb6067804b095aaf6371fc1983e Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181217204046.14861-1-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Long line wrapped] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-14qapi: add condition to variants documentationMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-21-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-14qapi: add 'If:' condition to struct members documentationMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-20-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-14qapi: add 'If:' condition to enum values documentationMarc-André Lureau
Use a common function to generate the "If:..." line. While at it, get rid of the existing \n\n (no idea why it was there). Use a line-break in member description, this seems to look slightly better in the plaintext version. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-19-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-14qapi: Add #if conditions to generated code membersMarc-André Lureau
Wrap generated enum and struct members and their supporting code with #if/#endif, using the .ifcond members added in the previous patches. We do enum and struct in a single patch because union tag enum and the associated variants tie them together, and dealing with that to split the patch doesn't seem worthwhile. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-18-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: add 'if' to alternate membersMarc-André Lureau
Add 'if' key to alternate members: { 'alternate': 'TestIfAlternate', 'data': { 'alt': { 'type': 'TestStruct', 'if': 'COND' } } } Generated code is not changed by this patch but with "qapi: add #if conditions to generated code". Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-17-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: add 'if' to union membersMarc-André Lureau
Add 'if' key to union members: { 'union': 'TestIfUnion', 'data': 'mem': { 'type': 'str', 'if': 'COND'} } The generated code remains unconditional for now. Later patches generate the conditionals. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-16-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: Add 'if' to implicit struct membersMarc-André Lureau
The generated code is for now *unconditional*. Later patches generate the conditionals. Note that union discriminators may not have 'if' conditionals. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-14-marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-15-marcandre.lureau@redhat.com> [Patches squashed, commit message tweaked] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: add a dictionary form for TYPEMarc-André Lureau
Wherever a struct/union/alternate/command/event member with NAME: TYPE form is accepted, desugar it to a NAME: { 'type': TYPE } form. This will allow to add new member details, such as 'if' in the following patch to introduce conditionals, or 'default' for default values etc. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-13-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi-events: add 'if' condition to implicit event enumMarc-André Lureau
Add condition to QAPIEvent enum members based on the event 'if'. The generated code remains unconditional for now. Later patches generate the conditionals (also there is no additional coverage of this change in qapi-schema-test.out since the event_names enum is an implicit type created by qapi/events.py). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-11-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: add 'if' to enum membersMarc-André Lureau
QAPISchemaMember gains .ifcond for enum members: inherited classes, such as QAPISchemaObjectTypeMember, will thus have an ifcond member after this (those different types will also use the .ifcond to store the condition and generate conditional code in the following patches). The generated code remains unconditional for now. Later patches generate the conditionals. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-10-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: add a dictionary form with 'name' key for enum membersMarc-André Lureau
Desugar the enum NAME form to { 'name': NAME }. This will allow to add new enum members, such as 'if' in the following patch. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-7-marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-8-marcandre.lureau@redhat.com> Message-Id: <20181213123724.4866-9-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Harmless accidental move backed out, long line wrapped, patches squashed] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: improve reporting of unknown or missing keysMarc-André Lureau
Report the set of missing or unknown keys. And give a hint about the accepted keys. The error message for multiple meta type members (visible in tests/qapi-schema/double-type.err) is not improved. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-6-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: factor out checking for keysMarc-André Lureau
Introduce a new helper function to check if the given keys are known, and if mandatory keys are present. The function will be reused in other places in the following code changes. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-5-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: change enum visitor and gen_enum* to take QAPISchemaMemberMarc-André Lureau
This will allow to add and access more properties associated with enum values/members, like the associated 'if' condition. We may want to have a specialized type QAPISchemaEnumMember, for now this will do. Modify gen_enum() and gen_enum_lookup() for the same reason. Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-3-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: Do not define enumeration value explicitlyMarc-André Lureau
The generated C enumeration types explicitly set the enumeration constants to 0, 1, 2, ... That's exactly what you get when you don't supply values. Drop the explicit values. No change now, but it will avoid gaps in the values when we later add support for 'if' conditions. Avoiding such gaps will save us the trouble of changing the ENUM_lookup[] tables to work without a sentinel. We'll have to take care to ensure the headers required by the 'if' conditions get always included before the generated QAPI code. Fortunately, our convention to include "qemu/osdep.h" first in any .c ensures that's the case for our CONFIG_FOO macros. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-2-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: rename QAPISchemaEnumType.values to .membersMarc-André Lureau
Rename QAPISchemaEnumType.values and related variables to members. Makes sense ever since commit 93bda4dd4 changed .values from list of string to list of QAPISchemaMember. Obvious no-op. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20181208111606.8505-4-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-08-28qapi: Add comments to aid debugging generated introspectionEric Blake
We consciously chose in commit 1a9a507b to hide QAPI type names from the introspection output on the wire, but added a command line option -u to unmask the type name when doing a debug build. The unmask option still remains useful to some other forms of automated analysis, so it will not be removed; however, when it is not in use, the generated .c file can be hard to read. At the time when we first introduced masking, the generated file consisted only of a monolithic C string, so there was no clean way to inject any comments. Later, in commit 7d0f982b, we switched the generation to output a QLit object, in part to make it easier for future addition of conditional compilation. In fact, commit d626b6c1 took advantage of this by passing a tuple instead of a bare object for encoding the output of conditionals. By extending that tuple, we can now interject strategic comments. For now, type name debug aid comments are only output once per meta-type, rather than at all uses of the number used to encode the type within the introspection data. But this is still a lot more convenient than having to regenerate the file with the unmask operation temporarily turned on - merely search the generated file for '"NNN" =' to learn the corresponding source name and associated definition of type NNN. The generated qapi-introspect.c changes only with the addition of comments, such as: | @@ -14755,6 +15240,7 @@ | { "name", QLIT_QSTR("[485]"), }, | {} | })), | + /* "485" = QCryptoBlockInfoLUKSSlot */ | QLIT_QDICT(((QLitDictEntry[]) { | { "members", QLIT_QLIST(((QLitObject[]) { | QLIT_QDICT(((QLitDictEntry[]) { Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180827213943.33524-3-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Rebased, update to qapi-code-gen.txt corrected] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-08-28qapi: Minor introspect.py cleanupsEric Blake
Commit 7d0f982b changed generated introspection output to no longer produce long lines in the generated .c file, but failed to adjust comments to match. Add some clarity that the shorter length that matters most is the overall QMP response on the wire. Commit 25b1ef31 triggers a pep8 formatting nit. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180827213943.33524-2-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-08-28qapi: Emit a blank line before dummy declarationMarkus Armbruster
We emit a dummy variable in each .c file "to shut up OSX toolchain warnings about empty .o files" (commit 252dc3105fc). Separate it from the code preceding it (if any) with a blank line. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180828120736.32323-2-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-08-28qapi: Drop qapi_event_send_FOO()'s Error ** argumentPeter Xu
The generated qapi_event_send_FOO() take an Error ** argument. They can't actually fail, because all they do with the argument is passing it to functions that can't fail: the QObject output visitor, and the @qmp_emit callback, which is either monitor_qapi_event_queue() or event_test_emit(). Drop the argument, and pass &error_abort to the QObject output visitor and @qmp_emit instead. Suggested-by: Eric Blake <eblake@redhat.com> Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180815133747.25032-4-peterx@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Commit message rewritten, update to qapi-code-gen.txt corrected] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-08-28qapi: Fix build_params() for empty parameter listMarkus Armbruster
build_params() returns '' instead of 'void' when there are no parameters. Can't happen now, but the next commit will change that. Signed-off-by: Markus Armbruster <armbru@redhat.com> [peterx: compose the patch from email replies] Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180815133747.25032-3-peterx@redhat.com>
2018-08-15qapi: Fix some pycodestyle-3 complaintsMarkus Armbruster
Fix the following issues: common.py:873:13: E129 visually indented line with same indent as next logical line common.py:1766:5: E741 ambiguous variable name 'l' common.py:1784:1: E305 expected 2 blank lines after class or function definition, found 1 common.py:1833:1: E305 expected 2 blank lines after class or function definition, found 1 common.py:1843:1: E305 expected 2 blank lines after class or function definition, found 1 visit.py:181:18: E127 continuation line over-indented for visual indent Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180621083551.775-1-armbru@redhat.com> [Fixup squashed in:] Message-ID: <871sd0nzw9.fsf@dusky.pond.sub.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-07-23qapi: Make 'allow-oob' optional in SchemaInfoCommandMarkus Armbruster
Making 'allow-oob' optional in SchemaInfoCommand permits omitting it in the common case. Shrinks query-qmp-schema's output from 122.1KiB to 118.6KiB for me. Note that out-of-band execution is still experimental (you have to configure the monitor with x-oob=on to use it). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180718090557.17248-1-armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2018-07-16qapi: Do not expose "allow-preconfig" in query-qmp-schemaMarkus Armbruster
According to commit 047f7038f58, option --preconfig [...] allows pausing QEMU in the new RUN_STATE_PRECONFIG state, allowing the configuration of QEMU from QMP before the machine jumps into board initialization code of machine_run_board_init() The intent is to allow management to query machine state and additionally configure it using previous query results within one QEMU instance (i.e. eliminate the need to start QEMU twice, 1st to query board specific parameters and 2nd for actual VM start using query results for additional parameters). The implementation is a bit of a hack: it splices in an additional main loop before machine creation, in special runstate preconfig. New command exit-preconfig exits that main loop. QEMU continues initializing, creates the machine, and runs the good old main loop. The replacement of the main loop is transparent to monitors. Sadly, some commands expect initialization to be complete. Running them in --preconfig's main loop violates their preconditions. Since we don't really know which commands are safe, we use a whitelist. This drags the concept of run state into the QMP core. The whitelist is done as a command flag in the QAPI schema (commit d6fe3d02e9a). Drags the concept of run state further into the QAPI language. The command flag is exposed in query-qmp-schema (also commit d6fe3d02e9a). This makes it ABI. I consider the whole thing an offensively ugly hack, but sometimes an ugly hack is the best we can do to solve a problem people have. The need described by the commit message quote above is genuine. The proper solution would be a main loop that permits complete configuration via QMP. This is out of reach, thus the hack. However, even though the need is genuine, it isn't urgent: libvirt is not going to use this anytime soon. Baking a hack into ABI before it has any users is a bad idea. This commit reverts the parts of commit d6fe3d02e9a that affect ABI via query-qmp-schema. The commit did the following: (1) Add command flag 'allow-preconfig' to the QAPI schema language (2) Pass it to code generators (3) Have the commands.py code generator pass it to the command registry (so commit 047f7038f58 can use it as whitelist) (4) Add 'allow-preconfig' to SchemaInfoCommand (neglecting to update qapi-code-gen.txt section "Client JSON Protocol introspection") (5) Set 'allow-preconfig': true for commands qmp_capabilities, query-commands, query-command-line-options, query-status Revert exactly (4), plus a bit of documentation added to qemu-tech.info in commit 047f7038f58. Shrinks query-qmp-schema's output from 126.5KiB to 121.8KiB for me. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180705091402.26244-2-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> [Straightforward conflict with commit d626b6c1ae7 resolved]
2018-07-03qapi: add 'If:' section to generated documentationMarc-André Lureau
The documentation is generated only once, and doesn't know C pre-conditions. Add 'If:' sections for top-level entities. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-13-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi-types: add #if conditions to types & visitorsMarkus Armbruster
Types & visitors are coupled and must be handled together to avoid temporary build regression. Wrap generated types/visitor code with #if/#endif using the context helpers. Derived from a patch by Marc-André. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-12-marcandre.lureau@redhat.com>
2018-07-03qapi/events: add #if conditions to eventsMarc-André Lureau
Wrap generated code with #if/#endif using an 'ifcontext' on QAPIGenCSnippet objects. This makes a conditional event's qapi_event_send_FOO() compile-time conditional, but its enum QAPIEvent member remains unconditional for now. A follow up patch "qapi-event: add 'if' condition to implicit event enum" will improve this. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-11-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi/commands: add #if conditions to commandsMarc-André Lureau
Wrap generated code with #if/#endif using an 'ifcontext' on QAPIGenCSnippet objects. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180703155648.11933-10-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Line breaks tweaked] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi-introspect: add preprocessor conditions to generated QLitMarc-André Lureau
This commit adds 'ifcond' conditions to top-level QLit objects. Future work will add them to object and enum type members, i.e. within QLit objects. Extend the QLit generator to_qlit() to accept (@obj, @cond) tuples in addition to just @obj. The tuple causes the QLit generated for objects for @obj with #if/#endif conditions for @cond. See generated tests/test-qmp-introspect.c. Example diff after this patch: --- before 2018-01-08 11:55:24.757083654 +0100 +++ tests/test-qmp-introspect.c 2018-01-08 13:08:44.477641629 +0100 @@ -51,6 +51,8 @@ { "name", QLIT_QSTR("EVENT_F"), }, {} })), +#if defined(TEST_IF_CMD) +#if defined(TEST_IF_STRUCT) QLIT_QDICT(((QLitDictEntry[]) { { "arg-type", QLIT_QSTR("5"), }, { "meta-type", QLIT_QSTR("command"), }, @@ -58,12 +60,16 @@ { "ret-type", QLIT_QSTR("0"), }, {} })), +#endif /* defined(TEST_IF_STRUCT) */ +#endif /* defined(TEST_IF_CMD) */ Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-9-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi-introspect: modify to_qlit() to append ',' on level > 0Marc-André Lureau
The following patch is going to break list entries with #if/#endif, so they should have the trailing ',' as suffix. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-8-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi: add #if/#endif helpersMarc-André Lureau
Add helpers to wrap generated code with #if/#endif lines. A later patch wants to use QAPIGen for generating C snippets rather than full C files with copyright headers etc. Splice in class QAPIGenCCode between QAPIGen and QAPIGenC. Add a 'with' statement context manager that will be used to wrap generator visitor methods. The manager will check if code was generated before adding #if/#endif lines on QAPIGenCSnippet objects. Used in the following patches. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180703155648.11933-7-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi: mcgen() shouldn't indent # linesMarc-André Lureau
Skip preprocessor lines when adding indentation, since that would likely result in invalid code. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-6-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi: add 'ifcond' to visitor methodsMarc-André Lureau
Modify the test visitor to check correct passing of values. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-5-marcandre.lureau@redhat.com> [Accidental change to roms/seabios dropped] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi: leave the ifcond attribute undefined until check()Marc-André Lureau
We commonly initialize attributes to None in .init(), then set their real value in .check(). Accessing the attribute before .check() yields None. If we're lucky, the code that accesses the attribute prematurely chokes on None. It won't for .ifcond, because None is a legitimate value. Leave the ifcond attribute undefined until check(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-4-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03qapi: pass 'if' condition into QAPISchemaEntity objectsMarc-André Lureau
Built-in objects remain unconditional. Explicitly defined objects use the condition specified in the schema. Implicitly defined objects inherit their condition from their users. For most of them, there is exactly one user, so the condition to use is obvious. The exception is wrapped types generated for simple union variants, which can be shared by any number of simple unions. The tight condition would be the disjunction of the conditions of these simple unions. For now, use the wrapped type's condition instead. Much simpler and good enough for now. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180703155648.11933-3-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>