On 2012-01-24 22:53, Anthony Liguori wrote: > On 01/24/2012 03:31 PM, Jan Kiszka wrote: >> On 2012-01-24 22:11, Anthony Liguori wrote: >>> On 01/24/2012 03:01 PM, Jan Kiszka wrote: >>>> On 2012-01-24 21:21, Anthony Liguori wrote: >>>>>> Also, I see a lot of programmatic initialization and a lot of >>>>>> repeating >>>>>> patterns (specifically regarding trivial class initialization) - >>>>>> there >>>>>> is no better alternative? >>>>> >>>>> Not really, no. It looks bad now because you have DeviceInfo still. >>>>> Once DeviceInfo goes away, all of the initialization will happen in >>>>> the >>>>> class_init function. >>>>> >>>>> The design of QOM is such that a lot of what was previously done via >>>>> declarative structures is now done imperatively. But the code bloat >>>>> that came in this patch series will decrease significantly with the >>>>> next >>>>> series as we eliminate DeviceInfo. >>>> >>>> Are there examples of fully converted devices to get an impression? >>> >>> https://github.com/aliguori/qemu/tree/qom-rebase.8 >>> >>> Has everything fully converted (including BusState). >>> >>> If you look at qdev.[ch], you'll notice the remaining qdev >>> infrastructure becomes greatly simplified. >> >> But I don't get yet why all these repeating initialization tasks need to >> be open-coded instead of remaining declarative. > > It would look like: > > static void device_generic_class_init(ObjectClass *klass, void *data) > { > DeviceClass *dc = DEVICE_CLASS(klass); > DeviceTypeInfo *ti = data; > > if (ti->reset) { > dc->reset = ti->reset; > } > if (ti->vmsd) { > dc->vmsd = ti->vmsd; > } > } > > void device_type_register_static(DeviceTypeInfo *ti) > { > TypeInfo ti = { > .class_init = device_generic_class_init, > .class_data = ti, > // ... > } > type_register_static(&ti); > } > > But I don't like this. The problem is that the declarative syntax we > have doesn't distinguish between "not-specified" and > "zero-initialized".
That's surely solvable. > It's also tempting to just drop the if (ti->reset) > check but that means that you unconditionally override the base class > implementation even if it's not specified. That as well, just wrap this repeating pattern in a macro. > > I don't see any tangible benefits to a declarative syntax except that it > makes it harder to get right because you have to write per-base class > initialization functions and it's very easy to get polymorphism wrong > there. Now you have to write way more derived class init functions - provided a base class is used more than once. > > We're not talking about a code size difference. It's a wash in terms of > number of lines of code. We are. Code size will be smaller, so the number of lines. How much, that depends on the number of users per base class. > > Imperative allows you to explicit zero-initialize, accept the previous > version (from the base class), or override with a new value. None of this is impossible with a declarative approach. Jan
signature.asc
Description: OpenPGP digital signature
