From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri09A-0002nf-Md for qemu-devel@nongnu.org; Tue, 03 Jan 2012 03:55:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ri099-000511-8x for qemu-devel@nongnu.org; Tue, 03 Jan 2012 03:55:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri098-00050q-Sx for qemu-devel@nongnu.org; Tue, 03 Jan 2012 03:55:03 -0500 Message-ID: <4F02C262.8040808@redhat.com> Date: Tue, 03 Jan 2012 09:54:58 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <87ehvis3uj.fsf@trasno.mitica> <4F01B542.8000800@suse.de> <4F01BB20.7020200@redhat.com> <4F0255E3.5030402@codemonkey.ws> In-Reply-To: <4F0255E3.5030402@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel , "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