[OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options

[Jonas Gorski]

On Mon, Dec 15, 2014 at 2:17 PM, Maxime Ripard
<maxime.ripard at 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.

Did you find any further kernel config options not covered by these?

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.

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.



Jonas
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel