On Thu, 2013-03-28 at 23:40 +0100, Hauke Mehrtens wrote: > > Now we can "source Kconfig.kernel" into our local Kconfig tree, and the > > "depends on USB" can magically work the right way. For the symbol walk > > (syms program above) we'll have to include an empty file, but that's not > > terribly difficult either. > > We also have to change all the select SOME_KERNEL_OPTION into a depends > SOME_KERNEL_OPTION, because the options of the used kernel can not be > changed. Huh, good point. I didn't think about that, and it probably doesn't even exist? But yeah, I agree, we need to do this. It's not terribly difficult though -- after we have a list of local symbols we can go through and rewrite "select NONLOCAL" to "depends on NONLOCAL". > compat should be changed in this way to not always backport any e.g. all > USB stuff and depend on USB stuff if the USB subsystem was not > activated. I think this should be modularized to have one *.ko for the > USB stuff, one for the PCMCIA stuff and so on. > Currently compat.ko depends on USB for some kernel versions. I don't think compat backports USB/PCMCIA/...? I was under the impression that it was necessary to be from the base kernel anyway, but I don't really know. In theory I agree, anything that's backported in compat needs to be included into the Kconfig somehow, particularly things like this. Actually, I guess we do have things like that now, just not USB/PCMCIA: CONFIG_COMPAT_FIRMWARE_CLASS CONFIG_COMPAT_NET_SCH_CODEL CONFIG_COMPAT_NET_SCH_FQ_CODEL CONFIG_COMPAT_KFIFO CONFIG_COMPAT_CORDIC CONFIG_COMPAT_CRC8 and something about CONFIG_GENERIC_ATOMIC64 on non-64 bit platforms. This is interesting! It probably means we need to generate a Kconfig file for the kernel versions as well, at build time: config COMPAT_KERNEL_2_6_26 def_bool y Obviously then compat relies more on compat-drivers to actually build? It could have its own Kconfig file, and probably best if the creation of this Kconfig.compat file is done through a script there. Anyway this is special. So we can treat it specially, and do something like config COMPAT_CORDIC bool default !CORDIC which should work just fine since we imported the symbols from the base kernel. We'll then get a CPTCFG_COMPAT_CORDIC symbol that we can use to build (or not) the cordic code. For something that depends on a specific kernel version it's just as simple: config COMPAT_FIRMWARE_CLASS tristate default m if COMPAT_KERNEL_2_6_33 && !COMPAT_RHEL_6_1 or so. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
