|
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 exercise.With the sample code, you must remove object_class_property_set calls at theDo 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
[Prev in Thread] | Current Thread | [Next in Thread] |