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 10:24:19 -0600 Message-ID: <4F315033.7060105@codemonkey.ws> References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F312C8A.9080700@redhat.com> <4F313BA8.9070601@codemonkey.ws> <4F31417F.2000102@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: quintela@redhat.com, =?ISO-8859-15?Q?Andreas_F=E4rber?= , KVM devel mailing list , Developers qemu-devel To: Paolo Bonzini Return-path: Received: from mail-pw0-f46.google.com ([209.85.160.46]:50798 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755258Ab2BGQYY (ORCPT ); Tue, 7 Feb 2012 11:24:24 -0500 Received: by pbdu11 with SMTP id u11so6009169pbd.19 for ; Tue, 07 Feb 2012 08:24:24 -0800 (PST) In-Reply-To: <4F31417F.2000102@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >