On 2010-04-19 11:40 PM, RHS Linux User wrote: > Hi All, > > <rant> > > This whole config business IMHO is a real mess! I disagree, it just takes a bit of getting used to.
> Can someone clarify what happens with target config, and whatever other > .configs that happen to be around somewhere? It works like this: you have target/linux/generic-2.6/config-<kernelversion>, which contains the baseline settings for all targets. Each target can override and add any config option relative to that. The delta is stored in target/linux/<platform>/config-<kernelversion>. The reason for that is that maintaining one individual .config for each target would create a much bigger mess, as it makes common config changes that affect all targets much harder to implement. > Also it seems to me HI TIME that .config became a VERY visible file. So > much depends on the "main" .config and the .config in the kernel > directory. For reasons stated above, we can't just stick the plain .config files from the kernel directories in the target dir, as this would mess up other things. > Is running make kernel_menuconfig the same as going into the kernel > directory and doing menuconfig there? (I hope so.) No, it's not. Make kernel_menuconfig does these things (simplified): - Generate the kernel's .config by merging the following files: - target/linux/generic-2.6/config-<kernelver> - target/linux/<platform>/config-<kernelver> - run make menuconfig in the kernel tree - subtract generic stuff from the kernel's .config and rebuild target/linux/<platform>/config-<kernelver> from that The idea is that you only need to hand-edit stuff if you want to make changes to the generic config template, which most of the time you don't have to. A bit more tricky is the interaction with the build system .config for selecting modules. The idea behind that is to not let the kernel build all modules all the time, but allow the user to select which modules to throw in binary packages. For this to work, the build system needs to make further modifications to the kernel's .config before launching the kernel module build, as having making these changes ahead of time for platform kernel configs would launch you into an unmanageable Dependency Tree From Hell. For all of the .config merges, scripts/kconfig.pl is used, which can do some very simple config merging/splitting operation. For the module selection it has a special operation that allows the merged-in config to only *upgrade* config selections. That means if you selected something as =y in kernel_menuconfig, the build system will not change that. It will however select stuff as =m or =y depending on the KCONFIG settings for kmod-* packages that you selected. Normally you don't have to be concerned with this process at all, however occasionally you may encounter undefined config symbols which make kernel_menuconfig or kernel_oldconfig won't show you. In this case, you need to add defaults for the missing symbols either to the KCONFIG line of the package that triggered them, or simply stick them into target/linux/generic-2.6/config-* I hope this clears things up a bit - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
