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

[Maxime Ripard]

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.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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141219/6272dddf/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel