aboutsummaryrefslogtreecommitdiff
path: root/tests/check-qom-proplist.c
AgeCommit message (Collapse)Author
2017-09-04qapi: drop the sentinel in enum arrayMarc-André Lureau
Now that all usages have been converted to user lookup helpers. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170822132255.23945-14-marcandre.lureau@redhat.com> [Rebased, superfluous local variable dropped, missing check-qom-proplist.c update added] Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-17-git-send-email-armbru@redhat.com>
2017-09-04qapi: Change data type of the FOO_lookup generated for enum FOOMarc-André Lureau
Currently, a FOO_lookup is an array of strings terminated by a NULL sentinel. A future patch will generate enums with "holes". NULL-termination will cease to work then. To prepare for that, store the length in the FOO_lookup by wrapping it in a struct and adding a member for the length. The sentinel will be dropped next. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170822132255.23945-13-marcandre.lureau@redhat.com> [Basically redone] Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-16-git-send-email-armbru@redhat.com> [Rebased]
2017-07-31tests: check-qom-proplist: fix leakMarc-André Lureau
user_creatable_add_opts() returns a reference (the other reference is for the root parent/child link). Leak introduced in commit a1af255f065cc. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-07-17qom: Fix ambiguous path detection when ambiguous=NULLEduardo Habkost
object_resolve_path*() ambiguous path detection breaks when ambiguous==NULL and the object tree have 3 objects of the same type and only 2 of them are under the same parent. e.g.: /container/obj1 (TYPE_FOO) /container/obj2 (TYPE_FOO) /obj2 (TYPE_FOO) With the above tree, object_resolve_path_type("", TYPE_FOO, NULL) will incorrectly return /obj2, because the search inside "/container" will return NULL, and the match at "/obj2" won't be detected as ambiguous. Fix that by always calling object_resolve_partial_path() with a non-NULL ambiguous parameter. Test case included. Reported-by: Igor Mammedov <imammedo@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170707213052.13087-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-07-17tests: Test case for object_resolve_path*()Eduardo Habkost
Test for partial path lookup using object_resolve_path*(). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170707213052.13087-2-ehabkost@redhat.com> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-06-06monitor: fix object_del for command-line-created objectsMichael Roth
Currently objects specified on the command-line are only partially cleaned up when 'object_del' is issued in either HMP or QMP: the object itself is fully finalized, but the QemuOpts are not removed. This results in the following behavior: x86_64-softmmu/qemu-system-x86_64 -monitor stdio \ -object memory-backend-ram,id=ram1,size=256M QEMU 2.7.91 monitor - type 'help' for more information (qemu) object_del ram1 (qemu) object_del ram1 object 'ram1' not found (qemu) object_add memory-backend-ram,id=ram1,size=256M Duplicate ID 'ram1' for object Try "help object_add" for more information which can be an issue for use-cases like memory hotplug. This happens on the HMP side because hmp_object_add() attempts to create a temporary QemuOpts entry with ID 'ram1', which ends up conflicting with the command-line-created entry, since it was never cleaned up during the previous hmp_object_del() call. We address this by adding a check in user_creatable_del(), which is called by both qmp_object_del() and hmp_object_del() to handle the actual object cleanup, to determine whether an option group entry matching the object's ID is present and removing it if it is. Note that qmp_object_add() never attempts to create a temporary QemuOpts entry, so it does not encounter the duplicate ID error, which is why this isn't generally visible in libvirt. Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Daniel Berrange <berrange@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1496531612-22166-3-git-send-email-mdroth@linux.vnet.ibm.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-06-06tests: check-qom-proplist: add checks for cmdline-created objectsMichael Roth
check-qom-proplist originally added tests for verifying that object-creation helpers object_new_with_{props,propv} behaved in similar fashion to the "traditional" method involving setting each individual property separately after object creation rather than via a single call. Another similar "helper" for creating Objects exists in the form of objects specified via -object command-line parameters. By that rationale, we extend check-qom-proplist to include similar checks for command-line-created objects by employing the same qemu_opts_parse()-based parsing the vl.c employs. This parser has a side-effect of parsing the object's options into a QemuOpt structure and registering this in the global QemuOptsList using the Object's ID. This can conflict with future Object instances that attempt to use the same ID if we don't ensure this is cleaned up as part of Object finalization, so we include a FIXME stub to test for this case, which will then be resolved in a subsequent patch. Suggested-by: Daniel Berrange <berrange@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Daniel Berrange <berrange@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1496531612-22166-2-git-send-email-mdroth@linux.vnet.ibm.com> [Comment formatting tidied up] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-09-08tests: fix check-qom-proplist leaksMarc-André Lureau
Found thanks to ASAN. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-06-07tests: Remove unnecessary glib.h includesPeter Maydell
Remove glib.h includes, as it is provided by osdep.h. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2016-03-22include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: Markus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-02-16tests: Clean up includesPeter Maydell
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com>
2016-01-18qom: Change object property iterator API contractDaniel P. Berrange
Currently the ObjectProperty iterator API works as follows: ObjectPropertyIterator *iter; iter = object_property_iter_init(obj); while ((prop = object_property_iter_next(iter))) { ... } object_property_iter_free(iter); This has the benefit that the ObjectPropertyIterator struct can be opaque, but has the downside that callers need to explicitly call a free function. It is also not in keeping with iterator style used elsewhere in QEMU/GLib2. This patch changes the API to use stack allocation instead: ObjectPropertyIterator iter; object_property_iter_init(&iter, obj); while ((prop = object_property_iter_next(&iter))) { ... } Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [AF: Fused ObjectPropertyIterator struct with typedef] Signed-off-by: Andreas Färber <afaerber@suse.de>
2016-01-18qom: Allow properties to be registered against classesDaniel P. Berrange
When there are many instances of a given class, registering properties against the instance is wasteful of resources. The majority of objects have a statically defined list of possible properties, so most of the properties are easily registerable against the class. Only those properties which are conditionally registered at runtime need be recorded against the klass. Registering properties against classes also makes it possible to provide static introspection of QOM - currently introspection is only possible after creating an instance of a class, which severely limits its usefulness. This impl only supports simple scalar properties. It does not attempt to allow child object / link object properties against the class. There are ways to support those too, but it would make this patch more complicated, so it is left as an exercise for the future. There is no equivalent to object_property_del() provided, since classes must be immutable once they are defined. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-11-18qom: Add a test case for complex property finalizationDaniel P. Berrange
Devices have some quite complex object child/link relationships which place some requirements on the object_property_del_all() function to consider that properties can be modified while being iterated over. This extends the QOM property test case to replicate the device like structure and expose any potential bugs in the object_property_del_all() function. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-11-18qom: Introduce ObjectPropertyIterator struct for iterationDaniel P. Berrange
Some users of QOM need to be able to iterate over properties defined against an object instance. Currently they are just directly using the QTAIL macros against the object properties data structure. This is bad because it exposes them to changes in the data structure used to store properties, as well as changes in functionality such as ability to register properties against the class. This provides an ObjectPropertyIterator struct which will insulate the callers from the particular data structure used to store properties. It can be used thus ObjectProperty *prop; ObjectPropertyIterator *iter; iter = object_property_iter_init(obj); while ((prop = object_property_iter_next(iter))) { ... do something with prop ... } object_property_iter_free(iter); Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Tested-by: Pavel Fedin <p.fedin@samsung.com> [AF: Fixed examples, style cleanups] Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-06-19qom: Don't pass string table to object_get_enum() functionDaniel P. Berrange
Now that properties can be explicitly registered as an enum type, there is no need to pass the string table to the object_get_enum() function. The object property registration already has a pointer to the string table. In changing this method signature, the hostmem backend object has to be converted to use the new enum property registration code, which simplifies it somewhat. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-06-19qom: Add an object_property_add_enum() helper functionDaniel P. Berrange
A QOM property can be parsed as enum using the visit_type_enum() helper function, but this forces callers to use the more complex generic object_property_add() method when registering it. It also requires that users of that object have access to the string map when they want to read the property value. This patch introduces a specialized object_property_add_enum() method which simplifies the use of enum properties, so the setters/getters directly get passed the int value. typedef enum { MYDEV_TYPE_FROG, MYDEV_TYPE_ALLIGATOR, MYDEV_TYPE_PLATYPUS, MYDEV_TYPE_LAST } MyDevType; Then provide a table of enum <-> string mappings static const char *const mydevtypemap[MYDEV_TYPE_LAST + 1] = { [MYDEV_TYPE_FROG] = "frog", [MYDEV_TYPE_ALLIGATOR] = "alligator", [MYDEV_TYPE_PLATYPUS] = "platypus", [MYDEV_TYPE_LAST] = NULL, }; Assuming an object struct of typedef struct { Object parent_obj; MyDevType devtype; ...other fields... } MyDev; The property can then be registered as follows: static int mydev_prop_get_devtype(Object *obj, Error **errp G_GNUC_UNUSED) { MyDev *dev = MYDEV(obj); return dev->devtype; } static void mydev_prop_set_devtype(Object *obj, int value, Error **errp G_GNUC_UNUSED) { MyDev *dev = MYDEV(obj); dev->devtype = value; } object_property_add_enum(obj, "devtype", mydevtypemap, "MyDevType", mydev_prop_get_devtype, mydev_prop_set_devtype, NULL); Note there is no need to check the range of 'value' in the setter, because the string->enum conversion code will have already done that and reported an error as required. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-06-19qom: Add object_new_with_props() / object_new_withpropv() helpersDaniel P. Berrange
It is reasonably common to want to create an object, set a number of properties, register it in the hierarchy and then mark it as complete (if a user creatable type). This requires quite a lot of error prone, verbose, boilerplate code to achieve. First a pair of functions object_set_props() / object_set_propv() are added which allow for a list of objects to be set in one single API call. Then object_new_with_props() / object_new_with_propv() constructors are added which simplify the sequence of calls to create an object, populate properties, register in the object composition tree and mark the object complete, into a single method call. Usage would be: Error *err = NULL; Object *obj; obj = object_new_with_propv(TYPE_MEMORY_BACKEND_FILE, object_get_objects_root(), "hostmem0", &err, "share", "yes", "mem-path", "/dev/shm/somefile", "prealloc", "yes", "size", "1048576", NULL); Note all property values are passed in string form and will be parsed into their required data types, using normal QOM semantics for parsing from string format. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>