[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 19:10:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

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

With the sample code, you must remove object_class_property_set calls at the

Do you mean object_property_set()?


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

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. :)


reply via email to

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