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

[Anthony Liguori]

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.