> > Well, "on" could have one defined meaning. Maybe it's the only option > > available, until drivers add intelligence. I don't see any problem > > with the other names being system-specific, since it's rather unlikely > > that a PCI_D3hot state will ever appear on most embedded ARM boxes. > > And if any userspace code tries to set power states, it had darn well > > better understand exactly what's going on. > > Yes. However if a network managing userspace code wants to set the power > conusmption of a WLAN device to the lowest possible setting, it shouldn't > need a configuration file specific for each platform. The current wireless extensions have power management calls, and I'd expect that whatever replaces them would do so as well. Which brings out a point I've made before: userspace power management should not as a rule be driven through /sys/devices/... files, but instead as part of the normal API to the devices. That's the best way to ensure that the operations fit into the devices' usage models, rather than as an ill-fitting frankenstein bolt-on. ;) > > That seems too complicated to me. When debugging, I want to visualize the > > entire tree ... so I'd want a /sys/kernel/debug/clocktree file, with lots > > of system-specific information. (Which gate bits are set/cleared? What > > speeds? etc.) Or else I just want to know which state the driver is in, > > like "mostly one". Some of that is taste, but also don't forget that each > > attribute in sysfs has a cost. > > Uh, there's a rule "one-value-per-file" for sysfs. Arrays might be OK in > certain cases, but lots of system-specific information in one file? No way, > IMHO. Remember that sysfs != debugfs, and /sys/kernel/debug is debugfs. Debugfs explicitly allows seq_printf() and friends. (And for that matter, binary data in sysfs is more than one-value-per-file ... there are plenty of cases where that "rule" doesn't need to be obeyed.) - Dave
