|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse |
Date: | Tue, 20 Dec 2011 14:51:14 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 |
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: 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. Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |