Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On 03/12/20 18:52, Eduardo Habkost wrote:
On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
> On 03/12/20 16:15, Kevin Wolf wrote:
>> I don't think this is an intermediate state like Eduardo wants to have.
>> Creating the object, then setting properties, then realize [1] will fail
>> after your change. But keeping it working was the whole point of the
>> exercise.
>
> With the sample code, you must remove object_class_property_set calls at the
Do you mean object_property_set()?
Yes.
> same time as you remove the setters. Usually that'd be when
you convert to
> QAPI and oc->configure, but it doesn't have to be that way if there are good
> reasons not to do so.
Having two (or more) similar but incompatible APIs to do exactly
the same thing is a mistake we did before, and I wouldn't like us
to repeat it.
If we can keep qdev_new() + object_property_set() + realize
working after the device is converted, we should. I believe we
can.
You can. If you want to do that, you have to give up on removing the
setters; but that's not so beneficial for devices because they already
use static properties anyway. They have much less boilerplate than
-object objects.
If we can make object_new_configure() work with all (or most)
device types before we manually convert them to the new system,
we should. I believe we can.
Yup, object_new_configure() is the low-level visitor-based API and
therefore it supports both properties and oc->configure.
We may be able avoid these questions with -object because
converting all backends at the same time is doable. With
devices, API usability and maintainability during the transition
period (which could be very long) needs to be taken into account.
I think we're in violent agreement. :)
Paolo