[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v14 10/21] qapi: permit auto-creating nested str

From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH v14 10/21] qapi: permit auto-creating nested structs
Date: Thu, 6 Oct 2016 17:10:42 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 30.09.2016 um 16:45 hat Daniel P. Berrange geschrieben:
> Some of the historical command line opts that had their
> keys in in a completely flat namespace are now represented
> by QAPI schemas that use a nested structs. When converting
> the QemuOpts to QObject, there is no information about
> compound types available, so the QObject will be completely
> flat, even after the qdict_crumple() call. So when starting
> a struct, we may not have a QDict available in the input
> data, so we auto-create a QDict containing all the currently
> unvisited input data keys. Not all historical command line
> opts require this, so the behaviour is opt-in, by specifying
> how many levels of structs are permitted to be auto-created.
> Note that this only works if the child struct is the last
> field to the visited in the parent struct. This is always
> the case for currently existing legacy command line options.
> The example is the NetLegacy type which has 3 levels of
> structs. The modern way to represent this in QemuOpts would
> be the dot-separated component approach
>   -net vlan=1,id=foo,name=bar,opts.type=tap,\
>        opts.data.fd=3,opts.data.script=ifup
> The legacy syntax will just be presenting
>   -net vlan=1,id=foo,name=bar,type=tap,fd=3,script=ifup
> So we need to auto-create 3 levels of struct when visiting.
> The implementation here will enable visiting in both the
> modern and legacy syntax, compared to OptsVisitor which
> only allows the legacy syntax.

So you're actually introducing the modern syntax only now?

I don't think an "opts.data." prefix makes a lot of sense. I suspect the
schema looks this way only because we didn't have flat unions in 1.2.

So, considering that it is a purely internally used type not visible in
QMP, would it make sense to change NetLegacy to be a flat union instead,
with NetLegacyOptions as the common base? Then you get the same flat
namespace that we always had and that makes much more sense as an API.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]