[Top][All Lists]

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

Re: [PATCH 00/18] qapi/qom: QAPIfy object-add

From: Paolo Bonzini
Subject: Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
Date: Thu, 3 Dec 2020 12:11:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 02/12/20 18:35, Kevin Wolf wrote:
Could we have an intermediate state that doesn't require any
duplication and thus have no separate code paths that could

The one requirement we have for an intermediate state is that it
supports both interfaces: The well-know create/set properties/realize
dance, and a new DeviceClass method, say .create(), that takes the
configuration in parameters instead of relying on previously set

I assumed two separate implementations of transferring the configuration
into the internal state. On second thought, this assumption is maybe

You can implement the new method as wrapper around the old way: It could
just set all the properties and call realize. Of course, you don't win
much in terms of improving the class implementation this way, but just
support the new interface, but I guess it can be a reasonable
intermediate step to resolve complicated dependencies etc.

I sketched something at https://wiki.qemu.org/Features/QOM-QAPI_integration.

The main difference with what we discussed so far is that it doesn't subsume the complete/realize step, only the setting of properties. The idea is that user_creatable_add_type does the following:

- calls an oc->configure method on every superclass of the object

- takes what's left of the input visitor and uses it to set properties

- then calls ucc->complete

So in the end the only new step is the first. If the first two steps are bundled in a new function object_configure, they can be reused for devices, machines and accelerators.

The QAPI code generator can also easily wrap them into a C API for QOM object creation.

I glossed completely over the generation of properties within the QAPI code generator. Making properties read-only (or, in the field-properties world, having a default allow_set of "return false") is already a nice improvement over

It would be much nicer to do the wrapper the other way round, i.e.
setting properties before the device is realized would update a
configuration struct and realize would then call .create() with that
struct. To me, this sounds much harder, though also a more useful state.

This sounds much harder. However, based on the RngEgd sample, going from a basic QAPI struct to a full conversion is not too hard and makes code shorter. So it's win-win even though it's human work.


reply via email to

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