On Mon, 29 Jun 2009 15:26:51 +1000 John Williams wrote: > Hi, > > Is there a mechanism to override or update a CONFIG_ value during the > make process? > > In the MicroBlaze architecture we have a highly configurable CPU - > various ALU options can be enabled or disabled at will during the > hardware build phase. We have several Kconfig options that must match > this, and which are used to generate the appropriate CFLAGS during > kernel build. e.g. > > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift > CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare > > MicroBlaze uses flat devices trees to configure the platform > (peripherals, memory, buses etc), but the device trees generated for > our systems also describe the CPU - exactly the info we need to > extract the right CPUFLAGS > > One of our make targets (not in mainline yet, but coming) - "make > simpleImage.<dtsname>" compiles and statically links the specified DTS > file into the kernel image. So, when making a simpleImage target, we > know at compile time exactly which hardware target we intend to boot. > > So, it would be nice if we can force the appropriate CPUFLAGS derived > directly from the DTS file, instead of relying on potentially > incorrect CONFIG_ values set by the user during menuconfig. The DTS > is just a text file, we can grep or awk over it to get what we need to > know. > > One way that occurs to me is to detect in arch/microblaze/Makefile > that a particular DTS file is provided, and if so then derive > CPUFLAGS-y from that, instead of from the CONFIG_ vars. This would be > pretty easy to achieve, but would require duplication of Makefile > content, also means that .config doesn't actually describe the kernel > that was build. autoconf.h and so on will also be wrong. Not ideal > for a trick that's aiming to improve correctness and reduce > hard-to-debug errors. > > Thus, returning to the question - is there a sane way that we can > override or force the relevant CONFIG_ values, from within the > Makefile itself? Or, must we resort to a script, and do it as a > preprocessing step? Is there a reasonable way to still integrate this > into the kernel build phase? I thought that it was possible to override CONFIG_ symbols on the "make" command line, and my limited testing confirms that. E.g.: make ARCH=x86_64 O=xx64 defconfig make CONFIG_HEADERS_CHECK=y CONFIG_BUILD_DOCSRC=y ARCH=x86_64 O=xx64 -j4 all does cause BUILD_DOCSRC builds to happen although BUILD_DOCSRC is not set in the defconfig file. (I set HEADERS_CHECK=y first since BUILD_DOCSRC depends on HEADERS_CHECK.) > A worst case approach is to just check the DTS against CONFIG_, and > error out if they don't match or form a downward-compatible subset. --- ~Randy LPC 2009, Sept. 23-25, Portland, Oregon http://linuxplumbersconf.org/2009/ -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
