On Aug 1, 2006, at 11:52 AM, Tim Bird wrote: > david singleton wrote: >> On Aug 1, 2006, at 3:09 AM, Matthew Locke wrote: >>> Well, no one is suggesting a user define and install that info. >>> Operating point creation will be done by someone who understands the >>> system (system designer) regardless of the method used to get the >>> operating points in the kernel. >> It sounds to me like they don't want to have to change kernel code >> and recompile the kernel >> to get a new operating point. >> It sounds like they are talking about a dynamic operating point as a >> loadable >> module, which would fit perfectly with the PowerOp scheme, since it's >> the >> system designer who would be creating the new dynamic operating >> point, >> not the user. > > Often, in the embedded world, the person defining the operating > states will not be a kernel developer, and may not be comfortable > with, or capable of, creating a kernel module. (There are > significant sections of the embedded space where modules are > not used at all, and no module support is compiled into the > kernel.) In these cases, requiring loadable module support > for runtime OPs would be a problem. As long as they can express them as supported operating points the way that CPUFREQ does those values can easily be translated into an operating point. A CPUFREQ table is a good example of this (see the powerop-x86-centrino.patch). We could provide a template powerop module where they'd just have to fill in the frequency, voltage information and they'd have a working module. > >> The point of PowerOp is that the system designer creates (and >> validates) >> the operating points that the hardware vendor supports, not the user. >> A system designer creating a new operating point as a loadable >> module would satisfy this requirement, and the user would not >> be able to put the system into an undefined state, either by accident >> or maliciously. >> > > OK, I think I understand better your objection to user-space > created operating points. In embedded projects, it is often > assumed that no one but the system designer has access to > arbitrary user space programs. Hence, it sometimes doesn't > register that an end user could or would utilize a particular > interface, just because it existed. > > Would not the normal Unix permissions system prevent the > "bad state" problem, in the non-embedded case? Not necessarily, the problem occurs when the user (root even) passes in a frequency or voltage that isn't quite supported. The value passes the ranges checks but when the clocks are set to the passed value the voltage is just below the edge where things still work. The system gets into an undefined state and usually hangs. This is the most common problem we have today with the Dynamic Power Management solution. David > > -- Tim > > ============================= > Tim Bird > Architecture Group Chair, CE Linux Forum > Senior Staff Engineer, Sony Electronics > ============================= >
