From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7 Date: Tue, 07 Feb 2012 08:56:40 -0600 Message-ID: <4F313BA8.9070601@codemonkey.ws> References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F312C8A.9080700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-15?Q?Andreas_F=E4rber?= , Developers qemu-devel , KVM devel mailing list , quintela@redhat.com To: Paolo Bonzini Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:59316 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752439Ab2BGO4q (ORCPT ); Tue, 7 Feb 2012 09:56:46 -0500 Received: by daed14 with SMTP id d14so453790dae.19 for ; Tue, 07 Feb 2012 06:56:46 -0800 (PST) In-Reply-To: <4F312C8A.9080700@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/2012 07:52 AM, Paolo Bonzini wrote: > On 02/07/2012 02:45 PM, Andreas F=E4rber wrote: >> Another topic that can be answered by email is what the time plannin= g >> for the 4th QOM series looks like. qom-upstream.16 is pretty close to ready to be sent out for v1. It's f= airly=20 tricky getting these things into a bisectable state. I think I've got = about a=20 days worth of work left so hopefully in terms of calendar time, probabl= y this=20 friday. In terms of merging, once it's gotten the appropriate reviews. This wo= n't be a=20 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=20 deprecating things, I'd prefer to deprecate by removing which basically= means=20 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=20 interfaces we really have to maintain compatibility for. =46or instance, the 4th series breaks setting -global properties based = on bus=20 name. But this is 1) not used by libvirt 2) not actually documented an= ywhere=20 and 3) such a subtle implementation detail that I don't think more than= a few=20 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 bec= ause it=20 puts children created by composition (like the Cirrus VGA adapter) in t= he same=20 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=20 instances, we'll have to fix it up manually but that really shouldn't b= e all=20 that hard. That gives us composition paths and a clear goal for removing the legac= y paths=20 (we'd want to work toward eliminating /legacy-machine). device_add doesn't use qdev_create() and neither would properly refacto= red=20 devices (they'd use object_init). Regards. Anthony Liguori > Paolo >