Re: Making QEMU easier for management tools and applications

[Markus Armbruster]

Marc-André Lureau <address@hidden> writes:

> Hi
>
> On Wed, Jan 15, 2020 at 1:21 PM Markus Armbruster <address@hidden> wrote:
>>
>> Christophe de Dinechin <address@hidden> writes:
>>
>> >> To make this worthwhile, we'd have to replace dynamic QOM properties by
>> >> static ones when possible.  Monumental task.
>> >
>> > I’m sure you are right, but it’s hard for me to evaluate, given how
>> > many ways there are to access an object. Naively, grepping for
>> > set_prop and for new_with_prop does not give me that many hits.
>>
>> Look for object_property_add*().  Some 450 hits.
>
> fwiw, I have started tackling that.

Laudable.

> Easy first step is to move all QDev properties to class properties,
> and this is done in :
> https://patchew.org/QEMU/address@hidden/

Easy because qdev properties are declarative by design.  Imperative came
in when they got rebased onto QOM.

> Moving from instance to class properties is straightforward many times
> (when the property is unconditonally added in instance init for
> example). There are a few complicated cases though.
>
> To me, the most problematic is reviewer-time and willingness to do
> such low-benefits changes.

Understand.

>> Basing the QAPI language on JSON was a poor choice.

Aggravated by immediately extending it in ways that defeat all common
JSON tools.

>>                                                      Not sure that's
>> fixable at a reasonable cost.
>
> Translating it to another language should be relatively easy, but to what?

The QAPI language is layered on top of JSON (see
docs/devel/qapi-code-gen.txt section "Schema syntax").  Swapping out
JSON for another language that is at least as expressive is an
relatively simple change.  Obvious candidates: s-expressions, TOML,
YAML.  The latter is far too complex for my taste.

The expensive part is dealing with the conflicts during the transition,
and having everybody relearn QAPI schema syntax.