hwdetect --modules
hwdetect --modules-not-loaded
to load all the necesserary modules before running
$ make localmodconfig
thx in advance
]]>I may revisit the script and add more logic to filter more out. If mod A depends on B or C and C has a direct relation to a module that is already loaded, then I can disable B. But developers got pretty fancy in their dependencies, so this logic will need to cope with that.
I wrote streamline_config.pl years ago (2005) as I was developing on several machines and I needed to cut down the time of the build. I did not have the time to figure out the modules for each of these machines (I had a new box every week), so I wrote this script to remove the modules not needed to boot the box, and speed up my productivity in compiling kernels.
I think it was 2 years ago at Kernel Summit, the topic came up that when someone reports a bug, and the developer asks the user to perform a git bisect to find the change that cause the bug, the user is reluctant because they only have a distro config and do not know enough to thin it down. A git bisect takes usually 13 full kernel compiles. This could take a week for someone with an old machine and a distro config. Linus Torvalds started yelling at the developers, asking why we do not have something that can trim down the config to speed up compile times for the users. One of the developers in attendance, that uses my script, answered him saying "We do, it's Steve Rostedt's streamline_config". Linus then asked why its not in the kernel already. The rest is history ;-)
So there you have it. The rational for why make localmodconfig is in the kernel.
My take is to make sure everything is enabled that will keep all your modules enabled too, even if it means keeping modules enabled that may not bee needed.
]]>All I can tell you is that when I run "make localmodconfig", it does not "turn off all the modules that are not loaded on your system", to quote from the "What it does?" comments at the top of the script.
When I run the script directly, as described in the "Howto" comments, it works as described.
]]>What the Kconfig files give you is the select and dependencies of configs. There are options that have a <M> state that do not translate into an actual file. But you may have a module that depends on that option being selected. If you run the script as you have, it will disable all module configs that do not have a direct association with a module, and that may disable the module you need when running menuconfig. For example: CONFIG_USB. If that is a module, you may be quite surprised at what you get when you run the script directly.
What you are seeing with the radeon and intel, is that you probably have one of those modules loaded, or a module that happened to have a dependency on one of those modules.
To keep the code less complex, any dependency is used. If module A depends on B or C, it will keep B and C even though only B is loaded. I may change this in the future, but so far I have not seen the point.
BTW, you do not need a .config in your source to run "make menuconfig", if no .config is around, it will look for one to use. The order it looks is: ".config", "/proc/config.gz", "/boot/config-<uname -r>", "/boot/vmlinuz-<uname -r>" (embedded configs), "vmlinux", "/lib/modules/<uname -r>/kernel/kernel/configs.ko, "kernel/configs.ko", "kernel/configs.o".
If you want to use a different lsmod (say from another machine). You can capture the output of the lsmod from another box "lsmod > mymods", and use that version in localmodconfig:
make LSMODE=mymods localmodconfig
]]>I had the same problem with localmodconfig, but I got it to work as intended by running the script - scripts/kconfig/streamline_config.pl - as recommended in the script's own comments.
Calling it from the kernel's Makefile seems to be the problem - someone should post a bug.
I finally got around to emailing the script's author, pointing him to this thread
]]>Is there any helpful guide for a kernel modules trim? I'm not sure how can I know which modules I can safely disable!
EDIT: I have a script in the AUR that keeps track of your modules for easy recall.
http://aur.archlinux.org/packages.php?ID=41689
Enjoy!
]]>Is there any helpful guide for a kernel modules trim? I'm not sure how can I know which modules I can safely disable!
This seems like a good advice: https://bbs.archlinux.org/viewtopic.php … 28#p829428
]]>Agreed - this is not something to be used in any automated context. The results have to be checked.
Agreed. It took me several iterations before I got all the modules that I need (I think)! Here are a few more statistics about running the compile with this option.
Processor: X3360 @ 3.40 GHz (Xeon version of the Q9550)
Memory: 8 GB of DDR2 @ 1,066.
Compiling in /dev/shm as we all should!
Stats for the kernel26-ck package without this option:
real compile time: 12m2.616s
# of modules: 2,572
package size: 28.54 MB
installed size: 141.24 MB
Stats for the kernel26-ck package with this option after first having modprobed a total of 95 modules:
real compile time: 2m30.607s
# of modules: 131
package size: 10.09 MB
installed size: 46.42 MB
Totals:
Compile time: 6x faster
# of modules: 20x less
Footprint on FS: 3x less
Pretty significant differences
FYI: here is the module set:
modprobe -a usb_storage loop udf nls_utf8 isofs twofish cifs vfat ext2 cryptd nls_cp437 aes-x86_64 serpent xts gf128mul dm_crypt fat aes_generic twofish_common dm_mod
Also see:
]]>OK - you've just proved my point.
You didn't use it as the writer intended, so it didn't work as intended. Start with a typical distro config, like the Arch one. Make sure all your devices are attached, and all the modules that you want to use with your slimmed-down kernel are loaded. Run the script - and I mean run the script, not 'make localmodconfig' - this thread exists because that make target appears to be broken.
Alternatively, just don't use it - you seem to be happy with your own way of doing things.
I would not know how to make fs more visible that it is now and missing xfs (this would render my system not bootable). I believe that this is most severe problem.
While I have no doubts that someone with experience will not have any problems fixing such issues, I think that for novice this might be too much. Still good learning tool.
I am not trashing the script/trolling, my intention is only to caution before localmodconfig will be added to any PKGBUILD. That is all.
]]>You didn't use it as the writer intended, so it didn't work as intended. Start with a typical distro config, like the Arch one. Make sure all your devices are attached, and all the modules that you want to use with your slimmed-down kernel are loaded. Run the script - and I mean run the script, not 'make localmodconfig' - this thread exists because that make target appears to be broken.
Alternatively, just don't use it - you seem to be happy with your own way of doing things.
]]>I draw my conclusion about localmodconfig after running following experiment:
1) create basic .config without any modifications and run localmodconfig
2) create optimized .config and run localmodconfig
3) run diff
results are really bad:
I have iwlwifi but at the moment I was connected through wired so module not loaded and missing from config file created by localmodconfig, also missing: fireware, missing some IDE stuff, but enabled ATA SFF which I don't have, enabled Tulip and 3Com and nvidia forcedeth (none of this present on my laptop)
while fireware was disabled, macintosh drivers were enabled (why?), also whole bunch of video/graphic drivers enabled (with potential issues for proper work of video card).
In conclusion I would have problems with my HDD, wireless network, video and few other things. In fact I would not be able to boot system at all: localmodconfig disabled XFS and enabled Ext3. Now I have /boot ext2 and the rest of partitions on xfs.
While I understand that Ext3 is preferable, this error kills any real use for localmodconfig. Whoever wrote this script should (instead of enabling all useless network drivers) make sure that at least system can boot so if there is no proven way of finding what fs system uses, then enable them all. Definitely more important than network.
In contrast when I was using as a "original" .config a file that I optimized, localmodconfig script left it almost unchanged, or rather changes made were not a big deal.
Now if I have to go and customize after localmodconfig customization, then this is useless tool not for any advanced user but in general for any real use as kernel configuration tool.
I do understand limitations of pre-defined configs, but this means that I do not have any use for something that will generate in effect poor quality product. I could leave .config as it is created by first run of old and tried menuconfig.
]]>