Re: [PATCH 0/5] Kconfig symbol cleanup for v5.4-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

The next step might be something like your automation. That looks hard,
though!

Does the above make sense?


Paul Bolle
_______________________________________________
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




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux