On Tuesday 02 June 2009 16:48:51 Dave Jones wrote: > On Tue, Jun 02, 2009 at 03:02:38PM +0200, Thomas Renninger wrote: > > > Locking in cpufreq subsystem always is/was a nightmare. > > I brought this up already and there were not much objections: > > > > Can we reduce complexity and disallow different governors on > > different > > cores? > > I think this is the way forward. It's hard to think of a use-case > where this is a useful feature. > Though we'd still have to go through the usual feature-removal > process. How would that look like?: The sysfs interface would be the same and these would be kept: /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor But it's enough to write to one instead of all and these should be links. Or does it make sense to introduce: /sys/devices/system/cpu/cpufreq/scaling_available_governors /sys/devices/system/cpu/cpufreq/scaling_governor and link above to these until deprecation time out is over. If /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is used, one could be told to use: /sys/devices/system/cpu/cpufreq/scaling_governor instead, because the other will fall off at some time. Beside documentation is there anything else to wait for implementing this? Thomas -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
