From the URL: <quote> ... a new build target has been added: make localmodconfig. It runs "lsmod" to find all the modules loaded on the current running system. It will read all the Makefiles to map which CONFIG enables a module. It will read the Kconfig files to find the dependencies and selects that may be needed to support a CONFIG. Finally, it reads the .config file and removes any module "=m" that is not needed to enable the currently loaded modules. With this tool, you can strip a distro .config of all the unuseful drivers that are not needed in our machine, and it will take much less time to build the kernel. There's an additional "make localyesconfig" target, in case you don't want to use modules and/or initrds. </quote> This is a very interesting development and has ramifications in terms of how we might provide an easier and less error-prone experience for the first-time Gentoo user. In particular, I believe that the genkernel path could significantly benefit from this feature. The process as it stands seems sub-optimal, to say the least. The handbook suggests that genkernel should be primed with the LiveCD config which, as I understand it, is because the bundled configs have fallen into a state of disrepair (something that ought to be independently addressed). The entire process hinges upon the use of a one-size-fits-all config which is cumbersome and time-consuming to build. The provision of the localmodconfig target would appear to allow for a comprehensive "seed" config, whilst providing for the first time not only a method of ensuring that the appropriate drivers are selected, but also providing a method of stripping out the numerous drivers that would not be needed for a given machine. Even where genkernel is not used, the localyesconfig target may well prove to a boon because it will guarantee that the Kconfig options correlating with the loaded modules will be compiled into the kernel statically. Thus, it has the potential to provide a much better experience for novice and/or first-time users, not to mention those who are simply not adept at configuring kernels. Having supported users for many years in the main IRC channel, it has become quite clear that the same tedious issues arise again and again. For instance, forgetting to compile in hard disk controller and/or filesystem support. Not to mention the confusion caused by the newer libata drivers (which is actually immensely complicated to explain and has a number of pre-requisites which are surprising to the uninitiated). I have also offered counsel to users whose kernels are misconfigured to the extent of having a severe impact on system performance on occasions to numerous for me to count [1]. These are timeless problems, but my point is that - when all is said and done - we have made absolutely no headway in terms of reducing the likelihood that these problems occur in the first instance. If anything, it has become more complicated than ever before. I would say that it constitutes the single-most significant barrier to entry and is a definitively user-hostile aspect of the installation process. The new feature is obviously not without its limitations. For instance, it would seem that it requires on a feature to be provided in the form of a module within the environment hosting the build in order to deem the related option necessary [2]. Therefore, its value is closely related to the quality of engineering that goes into the LiveCD, and favours a heavily modular approach. Nevertheless, I believe that, if these new make targets perform as advertised, we would do well to consider how we might factor them into the existing documentation and supporting tools. I have nothing precise to suggest at the current time; I have only recently learned of this feature and have not yet subjected it to any serious testing. Nevertheless, I am filing this bug in the hope of stimulating some discussion to that end. [1] This represents a somewhat different class of problem though: typically, that the upstream defconfig seldom makes any sense, and that we are not filling the gap by providing an intelligently designed 'seed' config. [2] I rather prefer the approach taken by Pappy's unofficial seeds project. Part of the process involves pasting an lspci -n dump into the form at http://kmuto.jp/debian/hcl/ - which promptly returns a hardware breakdown along with the relevant kernel module/options. So the matching is done on the basis of the hardware identifiers, rather than being tied to kernel modules that are loaded.
CC us if the kernel and/or genkernel teams do this, and when/if 2.6.32 goes stable. We can't do anything until then.
2.6.32 look pretty stable guys ;)
Any idea on this?
Interesting idea, if someone once to update documentation with this feature, please feel free to do so.
