Re: KVM call agenda for Tuesday 3

[Paolo Bonzini <pbonzini@redhat.com>]

On 01/03/2012 02:12 AM, Anthony Liguori wrote:
> 2/4 is on the list. It's adding the type infrastructure such that when
> you do -device e1000, as far as QOM is concerned you're creating an
> E1000 object which inherits from a PCIDevice, etc.

Yes, sorry, that was quite obvious.  I was not sure about what the other 
two parts were.

> But device creation still more or less happens with qdev. You couldn't
> directly create a useful E1000 device by doing object_new(TYPE_E1000).
>
> I just effectively squashed 3/4 and 4/4 into a single series. This new
> series (now 3/4) makes it so you can do object_new(TYPE_E1000). It
> basically reduces qdev to just the management of bus relationships.
>
> The new 4/4 series converts BusState to QOM. The effect is that a
> BusState is an Object (but not a device). The children are shown as
> links so the entire qdev tree is now just a subset of the QOM graph.
>
> I think that's it for infrastructure series. After that, the two areas
> I'm interested in focusing on are converting CPUs to qdev and then
> refactoring the pc machine init code to just essentially be a thin
> wrapper for object_new(TYPE_PC).

Nice.

>> In particular, we should decide as soon as possible about moving
>> features up from Device to Object or to new intermediate classes
>> (e.g. IntrospectableObject for properties?),
>
> I think I move properties from Device to Object in either 2/4 or 3/4.
> Anyway, that's my plan.

I would prefer to have an intermediate class for two reasons: 1) so that 
we can reuse refcounting and interfaces even for light-weight objects; 
2) so that we can keep interface implementations as subclasses of 
Object, without carrying a useless baggage for properties (that would be 
true for refcounting too, but the cost is much smaller).

Paolo