From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RunqH-0006dO-Mt for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:24:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RunqD-00075c-MA for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:24:29 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:54585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RunqD-00075S-E6 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:24:25 -0500 Received: by dadp14 with SMTP id p14so7749928dad.4 for ; Tue, 07 Feb 2012 08:24:24 -0800 (PST) Message-ID: <4F315033.7060105@codemonkey.ws> Date: Tue, 07 Feb 2012 10:24:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F312C8A.9080700@redhat.com> <4F313BA8.9070601@codemonkey.ws> <4F31417F.2000102@redhat.com> In-Reply-To: <4F31417F.2000102@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: Developers qemu-devel , =?ISO-8859-15?Q?Andreas_F=E4rber?= , KVM devel mailing list , quintela@redhat.com On 02/07/2012 09:21 AM, Paolo Bonzini wrote: > On 02/07/2012 03:56 PM, Anthony Liguori wrote: >>> 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. > > I'm wary of all plans that require to go through all the code once. What about > simply /devices/default/child[...] or something like that? The paths would be unstable, but maybe that's okay. I'd suggest doing child[rand()] to avoid the appearance that these paths are in any way shape or form stable. > BTW, I would like to change /i440fx to /devices/i440fx, so that we will have > clean namespaces: > > /block > ... > /chardev > ... > /clocks > ... > /devices > /peripheral > ... # named devices created with -device > /peripheral-anon > /child[...] # unnamed devices created with -device > /default > /child[...] # created with qdev_create Yeah, this makes sense. By clocks, you mean things like rtc_clock, vm_clock, etc? Not the omap clocks which happen to live in /clocks in your series? Regards, Anthony Liguori > > Paolo >