On Fri, 2006-11-24 at 01:36 -0500, Len Brown wrote: > On Friday 24 November 2006 00:17, Len Brown wrote: > > From: Zhang Rui <rui.zhang@xxxxxxxxx> > > > > Previously we used the device name in the DSDT, but would > > crash upon encountering a duplicate. Also, exposing > > the DSDT device name to the user in a path isn't a > > good idea, becauase it is arbitrary. > > So just add two attributes for each device, > > the full pathname in ACPI namespace and hardware_id. > > While this addresses the potential name conflict of the previous version, > I think this needs some work. > > $ ls /sys/devices/0 > 1 10 2 3 4 5 57 6 7 8 9 bus hid path power subsystem uevent > > Assigning the unique numbers in a depth-first search > leaves irritating gaps -- (see 10 and 57 above). That's true. But you know, ACPI namespace is a tree in nature. Depth-first is the fastest way to traverse the ACPI namespace. > Instance numbers need to be per-directory. > instance numbers should be unique in the whole ACPI bus, as all of them are linked to /sys/bus/acpi/devices/. > Also, IMHO, the numbers by themselves look a little strange, > maybe dev0, dev1, dev%d etc. wouldn't look so strange? > Yes, I can do that. :) > Also, the ACPI spec has some pre-defined root name-spaces, and I think > it makes sense to look up the device name against a small table of > those reserved names and print something more interesting than > a number. > > eg. > _SB system_bus > _PR processors > _TZ thermal_zones > _SI system_indicators > _GPE events > Yeah. I can do that. But few devices can benefit from this. :(. BTW: Maybe I can generate a patch to get the following result: Five devices with the fixed name shown above if they are declared in the BIOS And add a prefix for every devices, the prefix is one of fixed names, _SB _PR _TZ _SI _GPE. So devices are shown like _SB:dev001, _TZ:dev001, _PR:dev033 etc. But does this make sense? :( The best way is to define a unique and meaning rule to name all the ACPI devices. Unfortunately we haven't reached an agreement until now, but I think we can leave this for further discussion. > thanks, > -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
