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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
