From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5YNI-0003uc-FL for qemu-devel@nongnu.org; Mon, 19 Sep 2011 03:34:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5YNH-0005s1-8o for qemu-devel@nongnu.org; Mon, 19 Sep 2011 03:34:44 -0400 Received: from david.siemens.de ([192.35.17.14]:19079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5YNG-0005ru-Us for qemu-devel@nongnu.org; Mon, 19 Sep 2011 03:34:43 -0400 Message-ID: <4E76F08E.3060606@siemens.com> Date: Mon, 19 Sep 2011 09:34:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1316188834-13675-1-git-send-email-aliguori@us.ibm.com> <4E737DC9.5010208@siemens.com> <4E7393BA.9090209@us.ibm.com> In-Reply-To: <4E7393BA.9090209@us.ibm.com> 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: Peter Maydell , "qemu-devel@nongnu.org" , Markus Armbruster , Paolo Bonzini On 2011-09-16 20:21, Anthony Liguori wrote: > 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: I would not even store a name in the device unless it is user-assigned. That can be created on demand if we did our homework correctly. > > 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. As said in the other mail, the link name of the parent to its child is the name we need to look up here. In turn that means a child likely should know what link is referring to it in the composing parent. Can be a feature of a generic device link so that we can also easily walk graphs in both directions. > > 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. The parent creates the name, no question, but in a different way you still think of: by naming its link. Let's focus on how to do inter-device referencing. This is actually the more important topic IMO, but if we do it right, naming just falls out of it as a byproduct. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux