On Tue, 19.06.12 19:06, Colin Guthrie (gm...@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... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel