[systemd-devel] cpufrequtils considered useless

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 19/06/12 19:58 did gyre and gimble:
> On Tue, 19.06.12 19:06, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> 
>>> 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.
> 
> Well, but we actually try hard to make our systems as stateless as
> possible and not require / to be writable. i.e. we want to be able to
> boot the same image on real hardware of any kind, in a VM of any kind or
> in a container of any kind. But with making static changes to the OS
> like this you effectively break that logic...

Yeah but my comments were in the context of the options when running
under a 3.2 kernel. I'm obviously very much more in favour of the 3.3
approach with it's autoloading-fu which would negate the need for such
detection tools (and whether said tools write a static config or just do
the module loading themselves is really just down to boot speed really -
either approach has trade-offs)

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/