Re: [Qemu-devel] qapi: What does "'gen': false" actually do, and when should I use it?

[Paolo Bonzini <pbonzini@redhat.com>]

On 09/06/2015 10:42, Markus Armbruster wrote:
> Part 2: When to use it?
> 
> We use 'gen': false when we can't (be bothered to) specify the exact
> type of an argument or result.
> 
> Bad example: netdev_add
> 
>     We have arguments 'type': 'str' and '*props': '**'.
> 
>     We should have a union tagged by network backend type.  For each
>     type, the union holds the type's properties (if any).

The problem with this is that netdev_add was not type safe, because it
uses qemu_opts_from_qdict and QemuOpts is exclusively string-based.  So
you could write 'port': '123' or 'port': 123, and both would work, the
conversion to integer is done by the QemuOptsVisitor.

Note that device_add would have the same problem.

Paolo

> Better example: device_add (but that's not even QAPIfied, yet)
> 
>     If QAPIfied, we'd have arguments like 'driver': 'str' and '*props':
>     '**'.
> 
>     Looks just like netdev_add.  The difference is that network backends
>     and their properties are defined in one place, but device models and
>     their properties aren't.  They get collected at run time.  As long
>     as the schema is fixed at compile-time, it can't express the
>     resulting tagged union.
> 
> Another good example: qom-get
> 
>     We have a return value '**'.
> 
>     The run time type is the type of the property identified by the
>     arguments.  Therefore, the compile time type can only be the union
>     of all property types, which effectively boils down to "anything".
> 
>     The only way to say "anything" right now is '**'.  Requires 'gen':
>     false.  I figure we could extend the generators to support '**' in a
>     few places, which may let us avoid 'gen': false here.
> 
> Drawback of '**': introspection knows nothing.
> 
> Introspection knowing nothing about netdev_add's and device_add's
> acceptable properties is a big, painful gap.
> 
> Please don't invent new reasons for 'gen': false without a very
> compelling use case.  If you think you have one, we need to talk to make
> sure use of 'gen': false really beats the alternatives.  Alternatives
> may include extending the generators.
> 
>