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 #<number>, 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<parent-id>.child#<no> >>>>>> 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
