From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5YFK-00025L-TK for qemu-devel@nongnu.org; Mon, 19 Sep 2011 03:26:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5YFJ-0004Be-Cy for qemu-devel@nongnu.org; Mon, 19 Sep 2011 03:26:30 -0400 Received: from thoth.sbs.de ([192.35.17.2]:30146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5YFJ-0004BW-1E for qemu-devel@nongnu.org; Mon, 19 Sep 2011 03:26:29 -0400 Message-ID: <4E76EE9F.3020109@siemens.com> Date: Mon, 19 Sep 2011 09:26:23 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1316188834-13675-1-git-send-email-aliguori@us.ibm.com> <4E737DC9.5010208@siemens.com> <4E737F4C.7060907@codemonkey.ws> <4E738348.3080004@redhat.com> <4E738F65.3050403@codemonkey.ws> In-Reply-To: <4E738F65.3050403@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices (part 1) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Paolo Bonzini , Peter Maydell , "qemu-devel@nongnu.org" , Markus Armbruster On 2011-09-16 20:03, Anthony Liguori wrote: > On 09/16/2011 12:11 PM, Kevin Wolf wrote: >> Am 16.09.2011 18:54, schrieb Anthony Liguori: >>> This series just asks the device model developer to come up with a unique *when* >>> they're doing device composition. Even with a totally path based interface, >>> this is always going to be a firm requirement. >>> >>> I think it may be possible to eliminate required device names by having a formal >>> notion of composition and have the devices store the names of the composed >>> devices as part of the reference to that device. You could then have user >>> created devices use a separate hash table to track the names of those devices. >>> >>> But, we can't easily do this today. Having either a fully qualified name or a >>> composition name as part of qdev_create() is the Right Thing IMHO so I think >>> this is the stepping stone to something more sophisticated. >> >> Actually, as I said, I think this naming scheme is already by far too >> sophisticated. Jan is completely right, there is no point in duplicating >> paths in a name. Either we assign names only if the user specified one, >> or we auto-generate a really simple name that doesn't resemble a path, >> can be easily typed and is actually useful to have in addition to paths >> (my "#foo-1" suggestion). > > Names have to be relatively stable. Instantiation ordering should not affect > names nor should hotplug. Otherwise two device models will end up with devices > with different names. > > Jan's point is that there is a stable path that could be used for the name and > satisfy these purposes. This is the composition path. Either a device is > created by the user (and therefore has a stable name and sits on the '/' part of > the path) or is created through composition and has a derived named from a user > created device. Since the composed device is tied to its parent's lifecycle, > the path is always valid. > > So this is a simplification that I plan on running with. For now, I think this > series is the right next step because it gives us a path name for the name > (although different syntax) and let's us enforce that all devices has a > canonical path. For something that changes lots of devices and, at the same time, is going to be removed again, I'm hesitating to call it the right direction. A right step would be, IMHO, to introduce a generic introspectable device link so that parent devices can reference their children and a visitor can derive a child's relative name from that link name. Then make sure this link type is consistently used. I really dislike this focusing on assigning names internally and using them in QEMU-internal APIs. They should just fall out of the core when external interaction is required. > > Independent of that, Jan suggested that we could have what's essentially an > alias. This is just a short name (could be in the form '%s-%d' % > (class.lower(), object_count). This alias is just a hash table. It has nothing > to do with the core device model. I can't remember suggesting such thing. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux