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