|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] KVM call agenda for Tuesday 3 |
Date: | Tue, 03 Jan 2012 09:54:58 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |