On Sun, Feb 26, 2023 at 12:23:00PM -0700, Simon Glass wrote:
Hi Masahiro,
On Sun, 26 Feb 2023 at 10:36, Masahiro Yamada masahiroy@kernel.org wrote:
On Sun, Feb 26, 2023 at 11:44 PM Tom Rini trini@konsulko.com wrote:
On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote:
On Sun, Feb 26, 2023 at 11:04 PM Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada masahiroy@kernel.org wrote:
On Sat, Feb 25, 2023 at 11:38 AM Simon Glass sjg@chromium.org wrote: > > +Masahiro Yamada
I do not know. This seems a shorthand in Kconfig level.
masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc 540 1080 24872 masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc 163 326 7462
If hundreds of duplications are not manageable, go for it, but kconfig will be out-of-sync from the upstream Kconfig.
Yes that's right, it is a shorthand in Kconfig.
The counts above understand the problem a little since quite a few CONFIG options without an SPL prefix are used in SPL. We don't have tools to estimate how many, and we sometimes add a new symbol to 'gain control' of a particular feature in a phase.
My intent in sending this patch was to check whether this support for configuring multiple related builds (or something like it) could go upstream, which for Kconfig is Linux, I believe. What do you think?
This complexity is absolutely unneeded for Linux.
So, the answer is no.
Well, I think Simon summarized himself a bit shorter here than he did in the patch itself. So, to what extent does the kernel want to consider all of the other projects using the Kconfig language and their needs / use cases?
-- Tom
In principle, only features that are useful for Linux.
I'm disappointed in this attitude. It is the same thing that we saw from the DT bindings until recently.
Kconfig has small piece of code that is useful for other projects, for example,
#ifndef CONFIG_ #define CONFIG_ "CONFIG_" #endifwhich might be useful for Buildroot, but this is exceptionally small.
How about refactoring patches that would make a possible implementation easier to maintain, like [1] ? Would they be acceptable?
The multi-phase is too cluttered, and that is not what Linux wants to have.
Clearly it is not useful to Linux, which only has one build.
I'm honestly not sure about this part. I keep pondering if some of the module related options wouldn't be just as logical under a phases type thing. But it would also probably be more forcing a solution at a good-enough concept than finding a solution to a problem.