qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM call agenda for Tuesday 3


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]