qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Obj


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
Date: Tue, 24 Jan 2012 22:31:39 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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