[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert

From: Anthony Liguori
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
Date: Tue, 24 Jan 2012 15:53:57 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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?


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,
      // ...

But I don't like this. The problem is that the declarative syntax we have doesn't distinguish between "not-specified" and "zero-initialized". 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.

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.

We're not talking about a code size difference. It's a wash in terms of number of lines of code.

Imperative allows you to explicit zero-initialize, accept the previous version (from the base class), or override with a new value.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]