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:33:44 -0600 Message-ID: <4F315268.8030608@codemonkey.ws> References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F312C8A.9080700@redhat.com> <4F313BA8.9070601@codemonkey.ws> <4F31417F.2000102@redhat.com> <4F315033.7060105@codemonkey.ws> <4F3150F0.8060805@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Developers qemu-devel , =?ISO-8859-1?Q?Andreas?= =?ISO-8859-1?Q?_F=E4rber?= , KVM devel mailing list , quintela@redhat.com To: Paolo Bonzini Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:38550 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755288Ab2BGQdv (ORCPT ); Tue, 7 Feb 2012 11:33:51 -0500 Received: by mail-pz0-f46.google.com with SMTP id d14so525989dae.19 for ; Tue, 07 Feb 2012 08:33:51 -0800 (PST) In-Reply-To: <4F3150F0.8060805@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/2012 10:27 AM, Paolo Bonzini wrote: > On 02/07/2012 05:24 PM, Anthony Liguori wrote: >>> 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. > > Sounds a bit inconvenient for humans (who in the end are those who debug things > :)). There are tons of human readable paths to a single object so I don't think it's a problem. But no big deal with way since /devices/default should go away anyway. > >>> BTW, I would like to change /i440fx to /devices/i440fx, so that we >>> will have clean namespaces: >>> >>> /block >>> /chardev >>> /clocks >>> /devices >> >> 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? > > No, I really meant the OMAP clocks. :) Basically if you have an abstract > subclass TYPE_FOOS of TYPE_OBJECT, its instances would reside under /foos or > something easily related to "foos". Hrm, I don't like that very much. OMAP clocks are devices. Don't they belong in the devices hierarchy under the omap-clocks branch? The fact that they aren't DeviceState's is because DeviceState is a pile of cruft. Perhaps we should introduce a more streamlined Device base class and rename DeviceState to LegacyDevice or something like that. Regards, Anthony Liguori > > Paolo >