Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/20/2011 04:08 AM, Avi Kivity wrote:
> On 12/20/2011 12:03 PM, Avi Kivity wrote:
>> On 12/20/2011 04:46 AM, Anthony Liguori wrote:
>>>
>>> I would hope that you would agree that when designing the device
>>> model, we should aim to do what makes sense independent of migration.
>>> If we cannot achieve a certain feature with migration given the
>>> logical modeling of devices, it probably suggests that we need to
>>> improve our migration infrastructure.
>>>
>>> I assume that given the above, we all agree that separate devices is
>>> what makes the most sense ignoring migration.
>>
>> I don't agree with this.
>
> The problem with having two devices, is that now you have to identify
> the common code, put them somewhere, and use them as necessary.
>
> "apic" and "kvm-apic" both is-a (are-a?) "apic".  This suggests either a
> base class (containing the common code) and derived classes, or (like
> Jan's implementation), just one class, that defers part of the
> implementation to an interface implemented by two other classes.

Yes, a base-class is what I'm suggesting since this is what qdev is capable of 
today.

The other approach to this is to have an APICFrontend has-a APICBackend and then 
UserspaceAPIC is-a APICBackend and KernelAPIC is-a APICBackend.

You still now have three visible devices in the device model.  This is 
essentially what Jan's patches do today.

I think a simple base-class + subclass inheritance scheme makes the most sense here.

Regards,

Anthony Liguori

>
> Two unrelated classes which happen to implement exactly the same
> interface (vmstate fields) except one (visible name) and share some code
> are a strange solution to this problem.
>