From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: KVM call agenda for Tuesday 3 Date: Tue, 03 Jan 2012 09:54:58 +0100 Message-ID: <4F02C262.8040808@redhat.com> References: <87ehvis3uj.fsf@trasno.mitica> <4F01B542.8000800@suse.de> <4F01BB20.7020200@redhat.com> <4F0255E3.5030402@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel , "kvm@vger.kernel.org" To: Anthony Liguori Return-path: In-Reply-To: <4F0255E3.5030402@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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