'Twas brillig, and Kay Sievers at 19/06/12 11:10 did gyre and gimble: > On Tue, Jun 19, 2012 at 12:04 PM, Paul Menzel > <paulepan...@users.sourceforge.net> wrote: >> Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering: >>> On Tue, 19.06.12 11:42, Paul Menzel (paulepan...@users.sourceforge.net) >>> wrote: > >>>>>> I guess it is useful to have an abstraction layer because directories >>>>>> and files under `/sys` might change. >>>>> >>>>> Nah, really, cpufrequtils should just go away. People should use the >>>>> kernel APIs right away. >>>> >>>> alright looking into why `cpufrequtils` is installed on my system I now >>>> know the reasons. The frequency(?) modules are not loaded automatically >>>> and therefore the init.d script shipped by `cpufrequtils` is needed. >>> >>> This is a not the case anymore for kernels 3.3 and up anymore. CPU >>> feature modules are now loaded automatically based on the CPUID data. >> >> great news! So what should distributions having decided to use Linux 3.2 >> for their next stable release do? > > Update their kernel. :) > > Or do whatever they used to do in the past and bet it works, like it > did most of the time. The problem is pretty much solved from systemd's > point of view, so there will be no effort from this side. > > The only safe option was to compile all of the cpufreq modules into > the kernel. The drivers implement fallback and legacy support, so the > driver loading order is important. Userspace would need to know in > which order to try them out, which is seriously nothing userspace > should ever pretend to know.
The other option would be to have a small service that runs once, detects the relevant hardware and then setups up an appropriate modprobe.preload.d file (or similar) for use on subsequent boots. Detect once, then use static configs there after. Roll on 3.3. Nice to hear it's all automatic now :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
