On Fri, Apr 06, 2007 at 08:43:30AM -0700, David Brownell wrote: > > > If this patch starts to get deployed, I expect other people will find > > > a few other curiousities ... and likely some things to be fixed. > > > > > The /sys/devices/acpi_system:00/ tree is kind of new. I suspect one > > > way it could be more informative is to set up cross-links in sysfs > > > between the ACPI devices and the "real" device nodes ... e.g. on the > > > system I'm using right now .../device:00/PNP0A03:00/device:15/PNP0B00:00 > > > could have a link pointing to /sys/devices/pnp0/00:06 ... and that PNP > > > node in turn could have an "acpi" link pointing back to the ACPI thing. > > > > > > Such cross-links would let people see those relationships, and observe > > > which links are missing or otherwise strange. Fixing the bugs would > > > seem unlikely until those things become visible. > > > > Sounds nice. > > The patch below should make sense. > > Yeah, that's the idea. Let's see if it's any good. :) > > I'd just call it "acpi_node" not "ACPI_node" (NO POINT IN SHOUTING), > and might not even use the "_node" suffix. Yes, please don't shout :) > I cc'd Greg, who's our resident (or is that itinerant?) sysfs guru, > in case he has comments on this issue. Are you _sure_ you have a 1-to-1 relationship here? No multiple devices pointing to the same acpi node? Or the other way around? If so, you are going to have to change the name to be something more unique. Or how about "firmware" instead of "acpi" to be able to have the userspace tools work on any type of firmware that provides this, like openfirmware? thanks, greg k-h - 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
