"Daniel P. Berrange" writes:
> On Wed, Oct 12, 2016 at 11:18:21AM +0200, Markus Armbruster wrote:
>> "Daniel P. Berrange" writes:
>>
>> > When converting QemuOpts to a QObject, there is no information
>> > about compound types available,
>>
>> Yes, that's a drawback of splitting the conversion
On Wed, Oct 12, 2016 at 11:18:21AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > When converting QemuOpts to a QObject, there is no information
> > about compound types available,
>
> Yes, that's a drawback of splitting the conversion into a QemuOpts ->
> QObject part that
"Daniel P. Berrange" writes:
> When converting QemuOpts to a QObject, there is no information
> about compound types available,
Yes, that's a drawback of splitting the conversion into a QemuOpts ->
QObject part that is oblivious of types, and a QObject -> QAPI object
part that knows the types.
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> When converting QemuOpts to a QObject, there is no information
> about compound types available, so when visiting a list, the
> corresponding QObject is not guaranteed to be a QList. We
> therefore need to be able to auto-create a single element Q
When converting QemuOpts to a QObject, there is no information
about compound types available, so when visiting a list, the
corresponding QObject is not guaranteed to be a QList. We
therefore need to be able to auto-create a single element QList
from whatever type we find.
This mode should only be
