On Tue, Dec 16, 2014 at 01:43:03PM +0100, Jonas Gorski wrote: > On Mon, Dec 15, 2014 at 2:17 PM, Maxime Ripard > <maxime.rip...@free-electrons.com> wrote: > > On Sat, Dec 13, 2014 at 07:50:52PM +0100, Jonas Gorski wrote: > >> > Ok, I think most of it is because of options enabled by default. I > >> > wonder why that happens, but I also wonder why it hasn't been picked > >> > up by my tests. > >> > >> I already somewhat expected that. > >> > >> So make savedefconfig then likely dropped any non-generic non-arm > >> config symbols regardless whether they are at their default or > >> non-default values, causing these discrepancies on non-arm targets. > >> > >> The safest would be to create the reduced config-* as the union of all > >> target's savedefconfig results, but only using one for each ARCH might > >> also suffice. > > > > So, I just gave the union of all the config symbol a try, and while it > > fixes some issues, it also shows up something unexpected (logic, > > actually, but I didn't think of that). > > > > The differences that we have now are for the options that we enable > > through another way than the config-<version> file itself (like the > > target configuration, or the openwrt makefiles directly), that in turn > > have options that depends on them with a default to yes, and that we > > don't want to enable. > > > > In short, something like > > > > config FOO > > bool 'Some option' > > > > config BAR > > bool 'Some other option' > > depends on FOO > > default y > > > > If FOO is not enabled, the defconfig won't have any information on > > BAR, which means that if FOO gets enabled somehow, BAR will be set to > > y. > > > > I guess that in such a case, it should be up to the one that enables > > the FOO option to also enforce a BAR value if the default is not ok. > > > > That would be easy to do for the target configuration files, but not > > that much whenever it's a package that enables that option for > > example. > > > > And putting it in the global configuration kind of defeats the > > original purpose of this patch set. > > > > So I guess we should define a policy on this. What do you think? > > AFAIR, there are two places for "out-of-config" config symbols: > > a) config/Config-kernel.in, where several config symbols are directly > exposed as KERNEL_<foo>. There we can add appropriate additional > config symbols with our desired defaults (as is already done for a > few). > > b) KernelPackages in their KCONFIG sections. Adding the appropriate > BAR=n to the defintion that enables FOO should be sufficient.
Indeed, it's what I would find the more sensible. > Did you find any further kernel config options not covered by these? There's also target/linux/<target>/config-* that might introduce some of these, but that can be fixed directly in the file too. > Of course these are then two places which cannot be cleaned up > automatically, but they aren't new, and I don't think we can't get rid > of it. Actually, the current script I have ignores all of this, since it build the defconfig using the generic configuration, that doesn't have any of these three sources yet, so I guess we can just add them as we identify them, with a process similar to what you have now with the missing configuration options? > Btw, how do you propose to keep the list of symbols required current? > I doubt creating the union is a fast process. If you used a script for > that, I think it would be nice to also add it to scripts/, else nobody > will bother to do it again, and in a few kernel releases the generic > config-<foo> will then contain a lot of clutter again. It's actually quite fast. The current script I have is this one http://code.bulix.org/swedu2-87606 It's a bit hacky, and too specific to be merged as is, but it's something I can turn into something mergeable. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
