Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse

[Avi Kivity <avi@redhat.com>]

On 12/20/2011 03:51 PM, Paolo Bonzini wrote:
> On 12/20/2011 02:41 PM, Anthony Liguori wrote:
>> On 12/20/2011 03:56 AM, Avi Kivity wrote:
>>> On 12/20/2011 02:38 AM, Anthony Liguori wrote:
>>>>> That was v1 of my patches. Avi didn't like it, I tried it like this,
>>>>> and
>>>>> in the end I had to agree. So, no, I don't think we want such a
>>>>> model.
>>>>
>>>>
>>>> Yes, we do :-)
>>>>
>>>> The in-kernel APIC is a different implementation of the APIC device.
>>>> It's not an "accelerator" for the userspace APIC.
>>>
>>> A different implementation but not a different device. Device == spec.
>>
>> If it was hardware, it'd be a fully compatible clone. The way we would
>> model this is via inheritance.
>
> I see your fully compatible clone, and I raise my bridge with a
> different implementation underneath.  It's the same old debate on is-a
> vs has-a.
>
> In QOM parlance Jan implemented this:

QOM is the new C++

>
>     abstract class Object
>         abstract class Device
>             class APIC: { backend: link<APICBackend> }
>         abstract class APICBackend
>             class QEMU_APICBackend
>             class KVM_APICBackend
>
> and you're proposing this:
>
>     abstract class Object
>         abstract class Device
>             abstract class APIC
>                 class QEMU_APIC
>                 class KVM_APIC
>
> Both can be right, both can be wrong.

I don't mind either.  What I don't want:

  abstract class Object
     abstract class Device
        class APIC
        class KVMAPIC

-- 
error compiling committee.c: too many arguments to function