On Sun, Aug 14, 2011 at 19:01, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > (-cc: ARM/etc people; +cc: Kay) > > Dave Jones wrote: > >> If we have to move stuff again, we could do drivers/cpufreq/x86/ etc.. > > Unfortunately the old script used "find", not "ls", so that wouldn't > work. :/ > >> What we used to do in Fedora grew more and more complex over time. >> Here's the last incarnation: http://fpaste.org/uvDb/ > > The main difference from Debian seems to be that this script loads the > module corresponding to the chosen governor, while Debian's init > script loads all governor modules early (using a heuristic I would > like to avoid that involves running "find" to list them) and chooses > the governor to use later. Right, loading cpufreq drivers from userspace is fragile, and can not properly work today. Only the kernel itself know which driver to try to bind in which order. Modular cpufreq kernel modules make no real sense here with the infrastructure we have available today. >> In an ideal world, we'd auto-load the right module on a hotplug event >> from a cpu, but we're not there yet. I believe Kay is working on that. > > Yes, that is what I was hoping for. Are there patches to test? Yeah, it's on the TODO list, I just get too many 'really broken' things get sorted on top all time. :) But it will happen in the next months. > The comment at > http://thread.gmane.org/gmane.linux.kernel/796450/focus=796874 also > looks promising. That could work, but we better go right for the CPU specific aliases and do not try to load all of them, even when for completely different systems. That would just encode another workaround into kernel modules, which we better solve properly. Kay -- 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
