From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RumTV-0002Yg-DZ for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:56:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RumTP-0000Bu-JP for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:56:53 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:51392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RumTP-00006I-Ei for qemu-devel@nongnu.org; Tue, 07 Feb 2012 09:56:47 -0500 Received: by mail-pw0-f45.google.com with SMTP id a11so7978098pba.4 for ; Tue, 07 Feb 2012 06:56:46 -0800 (PST) Message-ID: <4F313BA8.9070601@codemonkey.ws> Date: Tue, 07 Feb 2012 08:56:40 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F312C8A.9080700@redhat.com> In-Reply-To: <4F312C8A.9080700@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: quintela@redhat.com, =?ISO-8859-15?Q?Andreas_F=E4rber?= , KVM devel mailing list , Developers qemu-devel On 02/07/2012 07:52 AM, Paolo Bonzini wrote: > On 02/07/2012 02:45 PM, Andreas Färber wrote: >> Another topic that can be answered by email is what the time planning >> for the 4th QOM series looks like. qom-upstream.16 is pretty close to ready to be sent out for v1. It's fairly tricky getting these things into a bisectable state. I think I've got about a days worth of work left so hopefully in terms of calendar time, probably this friday. In terms of merging, once it's gotten the appropriate reviews. This won't be a rebase-pain so we'll just treat it like a normal series. >> Are there things that developers of >> new devices should keep in mind / start doing differently wrt SysBus? It's probably a good time to read object.h if you haven't already. In terms of deprecating things, I'd prefer to deprecate by removing which basically means we'd only deprecate SysBus after converting all of the current users. A big consideration at this point is compatibility. It's not clear to me what interfaces we really have to maintain compatibility for. For instance, the 4th series breaks setting -global properties based on bus name. But this is 1) not used by libvirt 2) not actually documented anywhere and 3) such a subtle implementation detail that I don't think more than a few people even know it's possible. > Another related question is, should the 4th QOM series present a full > composition tree based on the legacy qdev bus concept? Composition, no. The legacy qbus concept doesn't model composition because it puts children created by composition (like the Cirrus VGA adapter) in the same context as a device created by a user (like an e1000 network card). > Currently it doesn't, but > if not, why not? That would help _a lot_ with removing PROP_PTR. One thing that we could do, is modify qdev_create() like: DeviceState *qdev_create_with_name(BusState *bus, const char *typename, const char *name) { // ... object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); // assert if err due to conflicting property names } DeviceState *qdev_create(BusState *bus, const char *typename) { return qdev_create_with_name(bus, typename, typename); } Most devices only have a single instance. In the cases where there are multiple instances, we'll have to fix it up manually but that really shouldn't be all that hard. That gives us composition paths and a clear goal for removing the legacy paths (we'd want to work toward eliminating /legacy-machine). device_add doesn't use qdev_create() and neither would properly refactored devices (they'd use object_init). Regards. Anthony Liguori > Paolo >