Messages in this thread | | | Date | Mon, 27 Feb 2023 13:00:43 -0500 | From | Tom Rini <> | Subject | Re: [PATCH] kconfig: Proposed language extension for multiple builds |
| |
On Mon, Feb 27, 2023 at 11:52:57PM +0900, Masahiro Yamada wrote: > Hi Simon, > > On Mon, Feb 27, 2023 at 1:00 PM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Masahiro, > > > > On Sun, 26 Feb 2023 at 20:36, Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > > > Hi Simon, > > > > > > On Mon, Feb 27, 2023 at 4:23 AM Simon Glass <sjg@chromium.org> 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. > > > > > > > > > Sorry, but this is the maintainer's job. > > > Saying no is one of the most important jobs as a maintainer. > > > > > > I must avoid Kconfig getting Frankenstein mechanisms. > > > > Can you suggest a better approach? > > > No, I can't. > > Kconfig is a configuration system of the Linux kernel, which is monolithic.
Well, Kconfig is a configuration system used by a dozen projects, that started out in Linux to replace the old Config.in system (which it has done a great job of, with my old timer hat on).
> It was not designed with multi-phase images in mind.
Yes, it was designed to move from the old Config.in to something better, that's why it still has "# FOO is not set" rather than FOO=n :)
> Presumably, Kconfig is good for U-Boot proper, but not for SPL/TPL given > the limited memory. There is little room for user's configuration anyway. > > U-Boot extended SPL too much. > On-chip RAM is not supposed to run DT, DM, FIT. > With SPL kept simple and ad-hoc, none of > CONFIG_SPL_OF_CONTROL, SPL_DM, SPL_FIT was unneeded. > "bootph-*" properties were unneeded either.
Yes, you disagree with the path U-Boot has taken in some areas. I do find this regrettable as you were a valued contributor to the project.
The place Kconfig is a bad fit in U-Boot isn't SPL/TPL/VPL, but for values, hex/int are used more in U-Boot than they are in the Linux kernel, which says something, and it's something we should deal with in U-Boot.
> This is a U-Boot-specific problem. > Please solve it in U-Boot.
Well, I keep going back and forth on if the modules part of the Linux kernel Kconfig and Kbuild system could be handled in a more clean, or just different manner, or not. And as Simon noted in the original email, Zephyr is likely to have the same conceptual issue soon enough. At a quick glance, barebox "PBL" could also make use of the Kconfig construct if they wanted (something like MCI_IMX_ESDHC could have "phases default pbl" added, instead of listing MCI_IMX_ESDHC_PBL later on). So I disagree that this is a problem specific to U-Boot, and that's why I've been encouraging Simon to bring this up more widely, so we can be good community members and help the Kconfig language community at large.
-- Tom [unhandled content-type:application/pgp-signature] | |