[CentOS] Kernel-utils stupidities (readahead and cpuspeed)

Hi all,

I think I've spotted a few stupidities (bugs) in the current version of 
kernel-utils (kernel-utils-2.4-13.1.80). I'm sure these are all propagated 
from upstream, but I hope someone could have a quick look to verify this and 
see if we either can push complaints upwards, or provide local fixes.

The kernel-utils package provides several 'kernel-type' functions - 
readahead and readahead_early and also the cpuspeed have a few problems;

readahead 'reads ahead' (stats to copy to cache for speedy access?) the 
files found in /etc/readahead.files. While most of these files are various 
images and common binaries, some are libraries which have been replaced by 
newer versions, thereby reducing the usefulness of readahead.

Readahead.early uses a different file (/etc/readahead.early.files) to cache 
useful system libraries, including a few kernel modules - for the 
2.6.3-2.1.238.2 kernel.

Both readahead and readahead.early are installed as disabled. chkconfig 
lists them as 'off' in all runlevels.

Worse, cpuspeed.
This is from an Athlon64 system, so it is possible that this behavior is 
different on non powernow-k8 systems.

On the CentOS4-x86_64 kernels, the cpuspeed-drivers are built into the 
kernel. Here, cpu speed-management works, as the 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver -file exists (tested for 
in /etc/init.d/cpuspeed). On CentOS4-i386, the powernow-k8-module is not 
built into the kernel, so the above test fails, and the cpuspeed startscript 
exits.

There seems to be a plan for this. The /etc/cpuspeed.conf file can specify a 
DRIVER variable, but no attempt is made to insmod this, so even if this is 
set, cpuspeed still fails. A simple fix is to check for the presence of the 
above /sys entry, and if that is missing, modprobe $DRIVER. Without this, 
cpuspeed will never work on my systems.
Does it work elsewhere?

Yours
-S
--
Simen Thoresen, Dolphin ICS