Hi Felix and All,
Thanks so much for your note.
Very insightful :).
So I am trying to enable MMC on Kamikaze 8.0.9 [actually the village
telco version]. I need to wind up with 3 kernel modules related to gpio
and mmc. I gather I start with kernel_menuconfig at the main level and
then do menuconfig? It is still confusing to me which boxes in the two
menuconfigs I check to get the various kernel modules whose names I know
compiled in. i.e.- the names on the selection boxes don't make it clear
which modules are going to be compiled? I feel like I must be missing some
simple step?
That said I am pretty sure I am close to having it working :).
Again thank you for your insightful response.
warm regards to all,
Wiz
On Tue, 20 Apr 2010, Felix Fietkau wrote:
> 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
