summary refs log tree commit diff stats
path: root/scripts/qapi/source.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2021-10-29qapi: Eliminate QCO_NO_OPTIONS for a slight simplificationMarkus Armbruster3-7/+2
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-Id: <20211028102520.747396-4-armbru@redhat.com>
2021-10-29qapi: Mark unstable QMP parts with feature 'unstable'Markus Armbruster4-45/+130
Add special feature 'unstable' everywhere the name starts with 'x-', except for InputBarrierProperties member x-origin and MemoryBackendProperties member x-use-canonical-path-for-ramblock-id, because these two are actually stable. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Message-Id: <20211028102520.747396-3-armbru@redhat.com>
2021-10-29qapi: New special feature flag "unstable"Markus Armbruster3-5/+16
By convention, names starting with "x-" are experimental. The parts of external interfaces so named may be withdrawn or changed incompatibly in future releases. The naming convention makes unstable interfaces easy to recognize. Promoting something from experimental to stable involves a name change. Client code needs to be updated. Occasionally bothersome. Worse, the convention is not universally observed: * QOM type "input-barrier" has properties "x-origin", "y-origin". Looks accidental, but it's ABI since 4.2. * QOM types "memory-backend-file", "memory-backend-memfd", "memory-backend-ram", and "memory-backend-epc" have a property "x-use-canonical-path-for-ramblock-id" that is documented to be stable despite its name. We could document these exceptions, but documentation helps only humans. We want to recognize "unstable" in code, like "deprecated". So support recognizing it the same way: introduce new special feature flag "unstable". It will be treated specially by the QAPI generator, like the existing feature flag "deprecated", and unlike regular feature flags. This commit updates documentation and prepares tests. The next commit updates the QAPI schema. The remaining patches update the QAPI generator and wire up -compat policy checking. Management applications can then use query-qmp-schema and -compat to manage or guard against use of unstable interfaces the same way as for deprecated interfaces. docs/devel/qapi-code-gen.txt no longer mandates the naming convention. Using it anyway might help writers of programs that aren't full-fledged management applications. Not using it can save us bothersome renames. We'll see how that shakes out. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-Id: <20211028102520.747396-2-armbru@redhat.com>
2021-10-27qapi: Implement deprecated-input={reject,crash} for enum valuesMarkus Armbruster4-6/+38
This copies the code implementing the policy from qapi/qmp-dispatch.c to qapi/qobject-input-visitor.c. Tolerable, but if we acquire more copies, we should look into factoring them out. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Message-Id: <20211025042405.3762351-5-armbru@redhat.com>
2021-10-27qapi: Move compat policy from QObject to generic visitorMarkus Armbruster8-36/+25
The next commit needs to access compat policy from the generic visitor core. Move it there from qobject input and output visitor. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20211025042405.3762351-4-armbru@redhat.com>
2021-10-27qapi: Add feature flags to enum membersMarkus Armbruster13-14/+57
This is quite similar to commit 84ab008687 "qapi: Add feature flags to struct members", only for enums instead of structs. Special feature flag 'deprecated' is silently ignored there. This is okay only because it will be implemented shortly. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20211025042405.3762351-3-armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2021-10-27qapi: Enable enum member introspection to show more than nameMarkus Armbruster4-10/+54
The next commit will add feature flags to enum members. There's a problem, though: query-qmp-schema shows an enum type's members as an array of member names (SchemaInfoEnum member @values). If it showed an array of objects with a name member, we could simply add more members to these objects. Since it's just strings, we can't. I can see three ways to correct this design mistake: 1. Do it the way we should have done it, plus compatibility goo. We want a ['SchemaInfoEnumMember'] member in SchemaInfoEnum. Since changing @values would be a compatibility break, add a new member @members instead. @values is now redundant. In my testing, output of qemu-system-x86_64's query-qmp-schema grows by 11% (18.5KiB). We can deprecate @values now and drop it later. This will break outmoded clients. Well-behaved clients such as libvirt are expected to break cleanly. 2. Like 1, but omit "boring" elements of @member, and empty @member. @values does not become redundant. @members augments it. Somewhat cumbersome, but output of query-qmp-schema grows only as we make enum members non-boring. There is nothing to deprecate here. 3. Versioned query-qmp-schema. query-qmp-schema provides either @values or @members. The QMP client can select which version it wants. There is no redundant output. We can deprecate old versions and eventually drop them. This will break outmoded clients. Breaking cleanly is easier than for 1. While 1 and 2 operate within the common rules for compatible evolution apply (section "Compatibility considerations" in docs/devel/qapi-code-gen.rst), 3 bypasses them. Attractive when operating within the rules is just too awkward. Not the case here. This commit implements 1. Libvirt developers prefer it. Deprecate @values in favour of @members. Since query-qmp-schema compatibility is pretty fundamental for management applications, an extended grace period is advised. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Message-Id: <20211025042405.3762351-2-armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2021-10-27qapi: Improve input_type_enum()'s error messageMarkus Armbruster8-12/+13
The error message claims the parameter is invalid: $ qemu-system-x86_64 -object qom-type=nonexistent qemu-system-x86_64: -object qom-type=nonexistent: Invalid parameter 'nonexistent' What's wrong is actually the *value* 'nonexistent'. Improve the message to qemu-system-x86_64: -object qom-type=nonexistent: Parameter 'qom-type' does not accept value 'nonexistent' Fixes: https://gitlab.com/qemu-project/qemu/-/issues/608 Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211020180231.434071-1-armbru@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2021-10-279pfs: use P9Array in v9fs_walk()Christian Schoenebeck1-12/+5
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <90c65d1c1ca11c1b434bb981b1fc7966f7711c8f.1633097129.git.qemu_oss@crudebyte.com>
2021-10-279pfs: make V9fsPath usable via P9Array APIChristian Schoenebeck2-0/+4
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <79a0ddf8375f6c95f0565ef155a1bf1e9387664f.1633097129.git.qemu_oss@crudebyte.com>
2021-10-279pfs: make V9fsString usable via P9Array APIChristian Schoenebeck2-0/+5
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <ce9f7a0a63585dc27f4545c485109efbec1251da.1633097129.git.qemu_oss@crudebyte.com>
2021-10-27