On Thu, Dec 03, 2020 at 07:10:37PM +0100, Paolo Bonzini wrote: > 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. Understood. We can also get rid of most setters in -object backends using field properties. Maybe not a necessary step, but a useful intermediate step in case the new API takes time to be ready. > > > 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. Perfect. That part was not clear yet to me (I just skimmed to the example code you posted on the wiki). > > > 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 > -- Eduardo
