Eric Blake <ebl...@redhat.com> writes:
> On 08/11/2017 11:05 AM, Markus Armbruster wrote:
>> We've wanted -object to support non-scalar properties for a while.
>> Dan Berrange tried in "[PATCH v4 00/10]Provide a QOM-based
>> authorization API". Review led to the conclusion that we need to
>> replace rather than add to QemuOpts. Initial work towards that goal
>> has been merged to provide -blockdev (commit 8746709), but there's
>> substantial work left, mostly due to an bewildering array of
>> compatibility problems.
>>
>> Even if a full solution is still out of reach, we can have a partial
>> solution now: accept -object argument in JSON syntax. This should
>> unblock development work that needs non-scalar properties with
>> -object.
>>
>> The implementation is similar to -blockdev, except we use the new
>> infrastructure only for the new JSON case, and stick to QemuOpts for
>> the existing KEY=VALUE,... case, to sidestep compatibility problems.
>>
>> If we did this for more options, we'd have to factor out common code.
>> But for one option, this will do.
>>
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> ---
>> qapi-schema.json | 14 +++++++++++---
>> vl.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 62 insertions(+), 3 deletions(-)
>>
>> static void object_create(bool (*type_predicate)(const char *))
>> {
>> + ObjectOptionsQueueEntry *e, *next;
>> +
>> + QSIMPLEQ_FOREACH_SAFE(e, &oo_queue, entry, next) {
>> + if (!type_predicate(e->oo->qom_type)) {
>> + continue;
>> + }
>> +
>> + loc_push_restore(&e->loc);
>> + qmp_object_add(e->oo->qom_type, e->oo->id,
>> + e->oo->has_props, e->oo->props, &error_fatal);
>> + loc_pop(&e->loc);
>> +
>> + QSIMPLEQ_REMOVE(&oo_queue, e, ObjectOptionsQueueEntry, entry);
>> + qapi_free_ObjectOptions(e->oo);
>> + }
>> +
>> if (qemu_opts_foreach(qemu_find_opts("object"),
>
> This handles all JSON forms prior to any QemuOpt forms (within the two
> priority levels), such that a command line using:
>
> -object type,id=1,oldstyle... -object '{'id':2, 'type':..., newstyle...}'
>
> processes the arguments in a different order than
>
> -object type,id=1,oldstyle... -object type,id=2,oldstyle
>
> But I don't see that as too bad (ideally, someone using the {} JSON
> style will use it consistently).
Yes, that's another restriction: if you need your -object evaluated in a
certain order, you may have to stick to one of the two syntax variants.
Aside: there are two sane evaluation orders: (1) strictly left to right,
and (2) order doesn't matter. QEMU of course does (3) unpredicable for
humans without referring back to the source code.
> Reviewed-by: Eric Blake <ebl...@redhat.com>
Thanks!
