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
