From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Fps-0003Du-H3 for qemu-devel@nongnu.org; Wed, 07 Sep 2011 06:58:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1Fpr-0002ie-Ai for qemu-devel@nongnu.org; Wed, 07 Sep 2011 06:58:28 -0400 Received: from david.siemens.de ([192.35.17.14]:22848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Fpq-0002iH-VK for qemu-devel@nongnu.org; Wed, 07 Sep 2011 06:58:27 -0400 Message-ID: <4E674E4E.7070501@siemens.com> Date: Wed, 07 Sep 2011 12:58:22 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E5BE735.3090706@us.ibm.com> <4E5BFCF8.3060206@web.de> <4E5C0250.3000807@codemonkey.ws> <4E5E7DFE.8050809@siemens.com> <20110907095051.GM15275@redhat.com> <4E67470B.1090107@siemens.com> <20110907103423.GN15275@redhat.com> In-Reply-To: <20110907103423.GN15275@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 6/6] qdev: Generate IDs for anonymous devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel , Markus Armbruster On 2011-09-07 12:34, Gleb Natapov wrote: > On Wed, Sep 07, 2011 at 12:27:23PM +0200, Jan Kiszka wrote: >> On 2011-09-07 11:50, Gleb Natapov wrote: >>> On Wed, Aug 31, 2011 at 08:31:26PM +0200, Jan Kiszka wrote: >>>> On 2011-08-29 23:19, Anthony Liguori wrote: >>>>> On 08/29/2011 03:56 PM, Jan Kiszka wrote: >>>>>> On 2011-08-29 21:23, Anthony Liguori wrote: >>>>>>> On 08/26/2011 09:48 AM, Jan Kiszka wrote: >>>>>>>> In order to address devices for that the user forgot or is even unable >>>>>>>> (no_user) to provide an ID, assign an automatically generated one. Such >>>>>>>> IDs have the format #, thus are outside the name space availing >>>>>>>> to users. Don't use them for bus naming to avoid any other user-visible >>>>>>>> change. >>>>>>> >>>>>>> I don't think this is a very nice approach. Why not eliminate anonymous >>>>>>> devices entirely and use a parent derived name for devices that are not >>>>>>> created by the user? >>>>>> >>>>>> This eliminates anonymous devices completely. So I guess you are asking >>>>>> for a different naming scheme, something like.child# >>>>>> e.g.? Well, we would end up with fairly long names when a complete >>>>>> hierarchy is anonymous. What would be the benefit? >>>>> >>>>> No, I'm saying that whenever a device is created, it should be given a >>>>> non-random name. IOW, the names of these devices should be stable. >>>>> >>>>>> I'm really just looking for some simple, temporary workaround without >>>>>> touching the existing fragile naming scheme. What we really need is full >>>>>> path addressing, but that without preserving all the legacy. >>>>> >>>>> Yeah, I understand, and I hesitated making any grander suggestions here, >>>>> but I'm not sure how much work it would be to just remove any caller >>>>> that passes NULL for ID and replace it with something more meaningful. I >>>>> think that's a helpful clean up long term no matter what. >>>> >>>> That won't solve the problem of finding a unique device name. If we want >>>> to derive it from stable device properties (bus addresses etc.), we >>>> first of all have to define them for all types of devices. And that's >>>> basically were the discussion exploded last year IIRC. >>>> >>> Why not use the OpenFirmware naming that we already have for some >>> devices instead of inventing something new? >> >> Because I do not want to establish any path names before QOM conversion >> (including potential device reorganization) has been started. > In theory device paths are dictated by HW topology, not today's flavor of > QEMU object model. There will be changes in the object composition, but predicting them today and modeling this on top of current qdev is nothing I want to try. > >> Specifically as I do not need naming for "some" devices, but for all. >> > It can be extended. We already have three types of device naming. One is > used in qdev, another is used for migration and yet another one for > passing device names to firmware. We should converge to a single one :) Yes, but that's beyond what this patch set can achieve or what will happen in foreseeable time. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux