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. Why can't a generic class init handler of TYPE_DEVICE not copy over all relevant fields from a, say, DeviceTypeInfo super-struct? And a sysbus class init handler could do the same from SysBusTypeInfo. That way you could define your device class again in a single struct instead of multiple ones + the init handler. If there are special needs, that handler would still be there. Jan
signature.asc
Description: OpenPGP digital signature
