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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html