On Thu, Oct 10, 2019 at 03:56:09PM +0200, Paul Bolle wrote:
Jeremy Cline schreef op do 10-10-2019 om 09:31 [-0400]:
> On Thu, Oct 10, 2019 at 02:20:54PM +0200, Paul Bolle wrote:
> > Anyhow, working on this I thought of a way to sort-of do this during
> > regular builds. I hope to work on that before v5.5-rc1. Stay tuned!
>
> So I *also* have a vague plan for this (but have not had time to
> implement it). The short version of the plan is have a Python script
> that walks the kernel Kconfig tree and compares it to our config
> snippets to find configurations that no long exist in the kernel and at
> the same time find the new configurations and drop them into the correct
> arch directories with a default value and the help text. That way the
> job of rebasing is also much easier.
>
> How does that line up with your plan?
My "sort-of" is your "vague"!
My current thinking is that it's odd that we generate the .config files in
three steps.
1: the entire configs/fedora/generic/... tree: we update this tree by hand,
basically;
2: the shipped kernel-*.config files: generated by build_configs.sh;
3: the .config files generated by the upstream Kconfig plumbing.
It would be much nicer if of all three would identical. (Which implies the
shipped kernel-*.config files would become superfluous.) And then we could
start by issuing warnings every time the configs/ tree and a generated .config
file get out of sync. (We already do this if we spot new Kconfig values in the
generated .config files. I think in process_configs.sh.)
The hardest part is that current configs/ tree cheats. It makes
# CONFIG_FOO_BAR is not set
also apply for the situation that CONFIG_FOO_BAR is invisible (or whatever the
proper Kconfig jargon is here). I need to play with my idea to see how
invisible Kconfig macros could be handled without cheating.
Interesting... The idea of "just one place" is a good one. There's been
some work on a maintenance approach where dist-git is all done
automatically and maintainers just deal with the upstream tree[0] and
there the situation is you just set it in the configs/ directory and
that's it (because the shipped kernel-*.config files are generated and
checked into the dist-git without human involvement.
The next step might be something like your automation. That looks hard,
though!
There's a Python library, kconfiglib, that is a pure Python
implementation of Kconfig. The problem is Kconfig seems to just be
whatever the kernel Kconfig tool can handle so kconfiglib often breaks
because of various small differences.
I got started on Python bindings using CFFI so we can just use Kconfig
directly from Python (I guess I could also just write the C code to do
this, but ugh). Once I finish those it should be pretty simple to do all
sorts of crazy config manipulations.
If you're interested in working on the CFFI bindings I can throw what I
have up on GitHub or something, but it's very much not functional at the
moment.
- Jeremy