From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4d2z-0001HY-7O for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:21:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4d2y-0002oV-1P for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:21:57 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:35564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4d2x-0002oJ-Tj for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:21:56 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Fri, 16 Sep 2011 14:21:54 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8GILmYr171058 for ; Fri, 16 Sep 2011 14:21:49 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8GILlte007499 for ; Fri, 16 Sep 2011 12:21:48 -0600 Message-ID: <4E7393BA.9090209@us.ibm.com> Date: Fri, 16 Sep 2011 13:21:46 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1316188834-13675-1-git-send-email-aliguori@us.ibm.com> <4E737DC9.5010208@siemens.com> In-Reply-To: <4E737DC9.5010208@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Jan Kiszka Cc: Peter Maydell , "qemu-devel@nongnu.org" , Markus Armbruster , Paolo Bonzini On 09/16/2011 11:48 AM, Jan Kiszka wrote: > On 2011-09-16 18:00, Anthony Liguori wrote: >> This series introduces an infrastructure to remove anonymous devices from qdev. >> Anonymous devices are one of the big gaps between qdev and QOM so removing is >> a prerequisite to incrementally merging QOM. >> >> Besides the infrastructure, I also converted almost all of the possible PC >> devices to have unique names. Please not that naming is not a property of >> devices but rather of the thing that creates the devices (usually machines). >> >> The names are ugly but this is because of the alternating device/bus hierarchy >> in qdev. For now, the names use '::' as deliminators but I think Jan has >> convinced me that down the road, we should use '/' as a deliminator such that >> the resulting names are actually valid paths (using a canonical path format). > > I still don't see why we need to store strings as device references. > Everyone that lacks a reference (QEMU-external users) can pass in a path > - which can be a device name in the simple case. Thinking more about this. I think a critical requirement is to be able to ask a device how to reference itself. IOW, there needs to be a device_get_name(dev) that returns something that can be meaningfully used to later reference the device. With your no name stored in a device proposal, you would have something like this: const char *device_get_name(Device *dev) { if (dev->parent) { // created through composition, ask parent return device_get_child_name(dev->parent, dev); } else { // user created, return user supplied name return dev->name; } } device_get_child_name() ends up becoming complicated unless you maintain a list of children and their name mappings. That means Device needs to store a hash table even though those pointers are not the canonical references since the composition devices are embedded in the parent Device. I think this leads to a lot of complexity without much real life gain. I think having the parent generate and set the child's name during creation is a significant simplification. Regards, Anthony Liguori That path is resolved > to an object reference before proceeding with the requested service. If > an object should be serialized in whatever way and we need a stable > name, a central service could return this by walking up the composition > tree until a user-assigned name is found. > > So there is really no need to bother device model developers with the > topics "How do I define a unique name?" or "Do I need an index or will > there be never more than one foo device?". > > Jan >