[PATCH] kconfig: Proposed language extension for multiple builds

[PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

In the case of Linux, only one build is produced so there is only a
single configuration. For other projects, such as U-Boot and Zephyr, the
same code is used to produce multiple builds, each with related (but
different) options enabled.

This can be handled with the existing kconfig language, but it is quite
verbose, somewhat tedious and very error-prone, since there is a lot of
duplication. The result is hard to maintain.

Describe an extension to the Kconfig language to support easier handling
of this use case.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 Documentation/kbuild/kconfig-language.rst | 134 ++++++++++++++++++++++
 1 file changed, 134 insertions(+)

diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index 858ed5d80defe..73fb016a5533f 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -228,6 +228,24 @@ applicable everywhere (see syntax).
   enables the third modular state for all config symbols.
   At most one symbol may have the "modules" option set.
 
+- phase declaration: "defphase"
+  This defines a new build phase. See `Build Phases`_.
+
+- default phase: "phasedefault"
+  This indicates the default build phase. See `Build Phases`_.
+
+- add entries for phases: "addphases"
+  This creates new phase-specific entries based on a template entry and adds
+  the same attributes to it. See `Build Phases`_.
+
+- set entries for phases: "setphases"
+  This sets the phases which need an entry. This allows creating an entry that
+  only has a primary phase. See `Build Phases`_.
+
+- indicate a phase-specific attribute: "forphases"
+  This marks an attribute as being applicable only to a particular phase or
+  group of phases.  See `Build Phases`_.
+
 Menu dependencies
 -----------------
 
@@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means it's only visible if
 MODULES is different from 'n'. The comment on the other hand is only
 visible when MODULES is set to 'n'.
 
+Build Phases
+------------
+
+Some projects use Kconfig to control multiple build phases, each phase
+resulting in a separate set of object files and executable. This is the
+case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_.
+
+Generally the phases are related, so that enabling an entry in the primary
+phase also enables it by default in the others. But in some cases it may
+be desirable to use separate conditions for each phase.
+
+All phases have a phase name, for example `SPL`. This name is used as a
+prefix to each entry used in that phase, with an underscore in between.
+So if FOO is the primary entry, the equivalent entry for the SPL phase
+is SPL_FOO. The primary phase is marked with a "phasedefault" entry.
+
+Phases are declared like any other menu entry except that also have a
+"defphase" keyword. Phase entries are normally hidden so do not have a
+prompt::
+
+    config PPL
+        bool
+        defphase "Primary Program Loader"
+        phasedefault
+        help
+          This is the primary bootloader.
+
+    config SPL
+        bool
+        defphase "Secondary Program Loader"
+        help
+          This is used to set up memory and load the primary bootloader.
+
+The default phase (here PPL) is assumed for all entries, in the sense that
+all entries are present in PPL by default and no prefix is needed on these
+entries. So FOO means that it applies to PPL. There must be exactly one
+default phase.
+
+The resulting menu entries can be used normally throughout the Kconfig. With
+this technique, the different build phases can be fully and individually
+controlled from Kconfig.
+
+However it is not ideal. Often the secondary phases have far fewer entries than
+the primary phase, since they offer fewer features. Even so, each FOO that is
+needed in a phase must have an SPL_FOO, etc. To avoid an explosion of entries,
+it is possible to indicate which are enabled, as a shortcut for creating new
+entries::
+
+    config FOO
+        bool "Enable foo feature"
+        addphases SPL
+        depends on %BAR
+        depends on QUX
+        forphases SPL depends on FIZZ
+
+Note that "%" expands to the phase, so this is equivalent to (ignoring BAR)::
+
+    config FOO
+        bool "Enable foo feature"
+        depends on BAR
+        depends on QUX
+
+    config SPL_FOO			   # Phase is prepended
+        bool "Enable foo feature (SPL)"    # Suffix is added
+        depends on SPL_BAR                 # "%" dependency is expanded
+        depends on QUX
+        depends on FIZZ                    # Added only for SPL
+        depends on SPL                     # Added automatically
+
+Attributes declared in the primary symbol FOO (such as "depends on BAR") also
+apply to the secondary ones.
+
+An entry without any 'addphases' attribute applies to all phases. Individual
+phase entries are not available in that case. If the entry is enabled, then
+it is enabled for all phases. Only one entry appears in the resulting Kconfig.
+
+In the case where an entry should apply only to the primary phase (or a
+particular set of phases), you can uses "setphases" instead of "addphases"::
+
+    config FOO
+        bool "Enable foo feature"
+        setphases PPL
+
+This means that even if the option is enabled, it will not be active outside
+the primary-phase build, here named "PPL".
+
+Internally, phases are implemented simply by creating new entries. These
+appear in the Kconfig as per normal. It would be possible for a Kconfig
+editor to show the entries just for a particular phase, leaving out the
+entries not applicable to that phase.
+
+When phases are used, the Kconfig tool outputs separate auto.conf files for
+each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
+`CONFIG_FOO=y` is present in the file. This makes it easy for the build system
+to build the correct code, use IS_ENABLED(), etc.
+
+To ensure that the correct options are enabled for each build, in addition to
+the normal CONFIG_FOO option in the file, phase symbols are added too. For
+example, if FOO is enabled in the SPL phase, then auto_spl.conf contains::
+
+    CONFIG_FOO=y
+    CONFIG_SPL_FOO=y
+
+The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it allows one
+phase to access the symbols from another phase. For example, if the primary
+phase needs to receive boot timings from SPL, then support for boot timings must
+be added in both phases. If the timings are at a fixed address, this can be in a
+shared symbol (like CONFIG_SPL_TIMING_BASE) that both phases can access.
+
+Technical note: the grammar definition of <symbol> in this documeent does not
+include the "%" prefix at present. It can be used with any attribute. It cannot
+be used with any top-level items, like "config", "menuconfig", "if" and "menu".
+
 
 Kconfig syntax
 --------------
@@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat
 .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
 .. [10] https://paulgazzillo.com/papers/esecfse21.pdf
 .. [11] https://github.com/paulgazz/kmax
+
+.. [12] https://u-boot.readthedocs.io/en/latest/develop/spl.html
+.. [13] https://docs.zephyrproject.org/latest/build/sysbuild/index.html
-- 
2.39.2.637.g21b0678d19-goog

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

Hi Masahiro,

On Sun, 19 Feb 2023 at 14:55, Simon Glass <sjg@chromium.org> wrote:
>
> In the case of Linux, only one build is produced so there is only a
> single configuration. For other projects, such as U-Boot and Zephyr, the
> same code is used to produce multiple builds, each with related (but
> different) options enabled.
>
> This can be handled with the existing kconfig language, but it is quite
> verbose, somewhat tedious and very error-prone, since there is a lot of
> duplication. The result is hard to maintain.
>
> Describe an extension to the Kconfig language to support easier handling
> of this use case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  Documentation/kbuild/kconfig-language.rst | 134 ++++++++++++++++++++++
>  1 file changed, 134 insertions(+)
>

Do you have any comments on this, please?

Regards,
Simon

> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index 858ed5d80defe..73fb016a5533f 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -228,6 +228,24 @@ applicable everywhere (see syntax).
>    enables the third modular state for all config symbols.
>    At most one symbol may have the "modules" option set.
>
> +- phase declaration: "defphase"
> +  This defines a new build phase. See `Build Phases`_.
> +
> +- default phase: "phasedefault"
> +  This indicates the default build phase. See `Build Phases`_.
> +
> +- add entries for phases: "addphases"
> +  This creates new phase-specific entries based on a template entry and adds
> +  the same attributes to it. See `Build Phases`_.
> +
> +- set entries for phases: "setphases"
> +  This sets the phases which need an entry. This allows creating an entry that
> +  only has a primary phase. See `Build Phases`_.
> +
> +- indicate a phase-specific attribute: "forphases"
> +  This marks an attribute as being applicable only to a particular phase or
> +  group of phases.  See `Build Phases`_.
> +
>  Menu dependencies
>  -----------------
>
> @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means it's only visible if
>  MODULES is different from 'n'. The comment on the other hand is only
>  visible when MODULES is set to 'n'.
>
> +Build Phases
> +------------
> +
> +Some projects use Kconfig to control multiple build phases, each phase
> +resulting in a separate set of object files and executable. This is the
> +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_.
> +
> +Generally the phases are related, so that enabling an entry in the primary
> +phase also enables it by default in the others. But in some cases it may
> +be desirable to use separate conditions for each phase.
> +
> +All phases have a phase name, for example `SPL`. This name is used as a
> +prefix to each entry used in that phase, with an underscore in between.
> +So if FOO is the primary entry, the equivalent entry for the SPL phase
> +is SPL_FOO. The primary phase is marked with a "phasedefault" entry.
> +
> +Phases are declared like any other menu entry except that also have a
> +"defphase" keyword. Phase entries are normally hidden so do not have a
> +prompt::
> +
> +    config PPL
> +        bool
> +        defphase "Primary Program Loader"
> +        phasedefault
> +        help
> +          This is the primary bootloader.
> +
> +    config SPL
> +        bool
> +        defphase "Secondary Program Loader"
> +        help
> +          This is used to set up memory and load the primary bootloader.
> +
> +The default phase (here PPL) is assumed for all entries, in the sense that
> +all entries are present in PPL by default and no prefix is needed on these
> +entries. So FOO means that it applies to PPL. There must be exactly one
> +default phase.
> +
> +The resulting menu entries can be used normally throughout the Kconfig. With
> +this technique, the different build phases can be fully and individually
> +controlled from Kconfig.
> +
> +However it is not ideal. Often the secondary phases have far fewer entries than
> +the primary phase, since they offer fewer features. Even so, each FOO that is
> +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of entries,
> +it is possible to indicate which are enabled, as a shortcut for creating new
> +entries::
> +
> +    config FOO
> +        bool "Enable foo feature"
> +        addphases SPL
> +        depends on %BAR
> +        depends on QUX
> +        forphases SPL depends on FIZZ
> +
> +Note that "%" expands to the phase, so this is equivalent to (ignoring BAR)::
> +
> +    config FOO
> +        bool "Enable foo feature"
> +        depends on BAR
> +        depends on QUX
> +
> +    config SPL_FOO                        # Phase is prepended
> +        bool "Enable foo feature (SPL)"    # Suffix is added
> +        depends on SPL_BAR                 # "%" dependency is expanded
> +        depends on QUX
> +        depends on FIZZ                    # Added only for SPL
> +        depends on SPL                     # Added automatically
> +
> +Attributes declared in the primary symbol FOO (such as "depends on BAR") also
> +apply to the secondary ones.
> +
> +An entry without any 'addphases' attribute applies to all phases. Individual
> +phase entries are not available in that case. If the entry is enabled, then
> +it is enabled for all phases. Only one entry appears in the resulting Kconfig.
> +
> +In the case where an entry should apply only to the primary phase (or a
> +particular set of phases), you can uses "setphases" instead of "addphases"::
> +
> +    config FOO
> +        bool "Enable foo feature"
> +        setphases PPL
> +
> +This means that even if the option is enabled, it will not be active outside
> +the primary-phase build, here named "PPL".
> +
> +Internally, phases are implemented simply by creating new entries. These
> +appear in the Kconfig as per normal. It would be possible for a Kconfig
> +editor to show the entries just for a particular phase, leaving out the
> +entries not applicable to that phase.
> +
> +When phases are used, the Kconfig tool outputs separate auto.conf files for
> +each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
> +`CONFIG_FOO=y` is present in the file. This makes it easy for the build system
> +to build the correct code, use IS_ENABLED(), etc.
> +
> +To ensure that the correct options are enabled for each build, in addition to
> +the normal CONFIG_FOO option in the file, phase symbols are added too. For
> +example, if FOO is enabled in the SPL phase, then auto_spl.conf contains::
> +
> +    CONFIG_FOO=y
> +    CONFIG_SPL_FOO=y
> +
> +The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it allows one
> +phase to access the symbols from another phase. For example, if the primary
> +phase needs to receive boot timings from SPL, then support for boot timings must
> +be added in both phases. If the timings are at a fixed address, this can be in a
> +shared symbol (like CONFIG_SPL_TIMING_BASE) that both phases can access.
> +
> +Technical note: the grammar definition of <symbol> in this documeent does not
> +include the "%" prefix at present. It can be used with any attribute. It cannot
> +be used with any top-level items, like "config", "menuconfig", "if" and "menu".
> +
>
>  Kconfig syntax
>  --------------
> @@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat
>  .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
>  .. [10] https://paulgazzillo.com/papers/esecfse21.pdf
>  .. [11] https://github.com/paulgazz/kmax
> +
> +.. [12] https://u-boot.readthedocs.io/en/latest/develop/spl.html
> +.. [13] https://docs.zephyrproject.org/latest/build/sysbuild/index.html
> --
> 2.39.2.637.g21b0678d19-goog
>

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

+lk

On Sun, 19 Feb 2023 at 14:55, Simon Glass <sjg@chromium.org> wrote:
>
> In the case of Linux, only one build is produced so there is only a
> single configuration. For other projects, such as U-Boot and Zephyr, the
> same code is used to produce multiple builds, each with related (but
> different) options enabled.
>
> This can be handled with the existing kconfig language, but it is quite
> verbose, somewhat tedious and very error-prone, since there is a lot of
> duplication. The result is hard to maintain.
>
> Describe an extension to the Kconfig language to support easier handling
> of this use case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  Documentation/kbuild/kconfig-language.rst | 134 ++++++++++++++++++++++
>  1 file changed, 134 insertions(+)
>
> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index 858ed5d80defe..73fb016a5533f 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -228,6 +228,24 @@ applicable everywhere (see syntax).
>    enables the third modular state for all config symbols.
>    At most one symbol may have the "modules" option set.
>
> +- phase declaration: "defphase"
> +  This defines a new build phase. See `Build Phases`_.
> +
> +- default phase: "phasedefault"
> +  This indicates the default build phase. See `Build Phases`_.
> +
> +- add entries for phases: "addphases"
> +  This creates new phase-specific entries based on a template entry and adds
> +  the same attributes to it. See `Build Phases`_.
> +
> +- set entries for phases: "setphases"
> +  This sets the phases which need an entry. This allows creating an entry that
> +  only has a primary phase. See `Build Phases`_.
> +
> +- indicate a phase-specific attribute: "forphases"
> +  This marks an attribute as being applicable only to a particular phase or
> +  group of phases.  See `Build Phases`_.
> +
>  Menu dependencies
>  -----------------
>
> @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means it's only visible if
>  MODULES is different from 'n'. The comment on the other hand is only
>  visible when MODULES is set to 'n'.
>
> +Build Phases
> +------------
> +
> +Some projects use Kconfig to control multiple build phases, each phase
> +resulting in a separate set of object files and executable. This is the
> +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_.
> +
> +Generally the phases are related, so that enabling an entry in the primary
> +phase also enables it by default in the others. But in some cases it may
> +be desirable to use separate conditions for each phase.
> +
> +All phases have a phase name, for example `SPL`. This name is used as a
> +prefix to each entry used in that phase, with an underscore in between.
> +So if FOO is the primary entry, the equivalent entry for the SPL phase
> +is SPL_FOO. The primary phase is marked with a "phasedefault" entry.
> +
> +Phases are declared like any other menu entry except that also have a
> +"defphase" keyword. Phase entries are normally hidden so do not have a
> +prompt::
> +
> +    config PPL
> +        bool
> +        defphase "Primary Program Loader"
> +        phasedefault
> +        help
> +          This is the primary bootloader.
> +
> +    config SPL
> +        bool
> +        defphase "Secondary Program Loader"
> +        help
> +          This is used to set up memory and load the primary bootloader.
> +
> +The default phase (here PPL) is assumed for all entries, in the sense that
> +all entries are present in PPL by default and no prefix is needed on these
> +entries. So FOO means that it applies to PPL. There must be exactly one
> +default phase.
> +
> +The resulting menu entries can be used normally throughout the Kconfig. With
> +this technique, the different build phases can be fully and individually
> +controlled from Kconfig.
> +
> +However it is not ideal. Often the secondary phases have far fewer entries than
> +the primary phase, since they offer fewer features. Even so, each FOO that is
> +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of entries,
> +it is possible to indicate which are enabled, as a shortcut for creating new
> +entries::
> +
> +    config FOO
> +        bool "Enable foo feature"
> +        addphases SPL
> +        depends on %BAR
> +        depends on QUX
> +        forphases SPL depends on FIZZ
> +
> +Note that "%" expands to the phase, so this is equivalent to (ignoring BAR)::
> +
> +    config FOO
> +        bool "Enable foo feature"
> +        depends on BAR
> +        depends on QUX
> +
> +    config SPL_FOO                        # Phase is prepended
> +        bool "Enable foo feature (SPL)"    # Suffix is added
> +        depends on SPL_BAR                 # "%" dependency is expanded
> +        depends on QUX
> +        depends on FIZZ                    # Added only for SPL
> +        depends on SPL                     # Added automatically
> +
> +Attributes declared in the primary symbol FOO (such as "depends on BAR") also
> +apply to the secondary ones.
> +
> +An entry without any 'addphases' attribute applies to all phases. Individual
> +phase entries are not available in that case. If the entry is enabled, then
> +it is enabled for all phases. Only one entry appears in the resulting Kconfig.
> +
> +In the case where an entry should apply only to the primary phase (or a
> +particular set of phases), you can uses "setphases" instead of "addphases"::
> +
> +    config FOO
> +        bool "Enable foo feature"
> +        setphases PPL
> +
> +This means that even if the option is enabled, it will not be active outside
> +the primary-phase build, here named "PPL".
> +
> +Internally, phases are implemented simply by creating new entries. These
> +appear in the Kconfig as per normal. It would be possible for a Kconfig
> +editor to show the entries just for a particular phase, leaving out the
> +entries not applicable to that phase.
> +
> +When phases are used, the Kconfig tool outputs separate auto.conf files for
> +each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
> +`CONFIG_FOO=y` is present in the file. This makes it easy for the build system
> +to build the correct code, use IS_ENABLED(), etc.
> +
> +To ensure that the correct options are enabled for each build, in addition to
> +the normal CONFIG_FOO option in the file, phase symbols are added too. For
> +example, if FOO is enabled in the SPL phase, then auto_spl.conf contains::
> +
> +    CONFIG_FOO=y
> +    CONFIG_SPL_FOO=y
> +
> +The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it allows one
> +phase to access the symbols from another phase. For example, if the primary
> +phase needs to receive boot timings from SPL, then support for boot timings must
> +be added in both phases. If the timings are at a fixed address, this can be in a
> +shared symbol (like CONFIG_SPL_TIMING_BASE) that both phases can access.
> +
> +Technical note: the grammar definition of <symbol> in this documeent does not
> +include the "%" prefix at present. It can be used with any attribute. It cannot
> +be used with any top-level items, like "config", "menuconfig", "if" and "menu".
> +
>
>  Kconfig syntax
>  --------------
> @@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat
>  .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
>  .. [10] https://paulgazzillo.com/papers/esecfse21.pdf
>  .. [11] https://github.com/paulgazz/kmax
> +
> +.. [12] https://u-boot.readthedocs.io/en/latest/develop/spl.html
> +.. [13] https://docs.zephyrproject.org/latest/build/sysbuild/index.html
> --
> 2.39.2.637.g21b0678d19-goog
>

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

+Masahiro Yamada <masahiroy@kernel.org>

On Fri, 24 Feb 2023 at 19:04, Simon Glass <sjg@chromium.org> wrote:

> +lk
>
> On Sun, 19 Feb 2023 at 14:55, Simon Glass <sjg@chromium.org> wrote:
> >
> > In the case of Linux, only one build is produced so there is only a
> > single configuration. For other projects, such as U-Boot and Zephyr, the
> > same code is used to produce multiple builds, each with related (but
> > different) options enabled.
> >
> > This can be handled with the existing kconfig language, but it is quite
> > verbose, somewhat tedious and very error-prone, since there is a lot of
> > duplication. The result is hard to maintain.
> >
> > Describe an extension to the Kconfig language to support easier handling
> > of this use case.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  Documentation/kbuild/kconfig-language.rst | 134 ++++++++++++++++++++++
> >  1 file changed, 134 insertions(+)
> >
> > diff --git a/Documentation/kbuild/kconfig-language.rst
> b/Documentation/kbuild/kconfig-language.rst
> > index 858ed5d80defe..73fb016a5533f 100644
> > --- a/Documentation/kbuild/kconfig-language.rst
> > +++ b/Documentation/kbuild/kconfig-language.rst
> > @@ -228,6 +228,24 @@ applicable everywhere (see syntax).
> >    enables the third modular state for all config symbols.
> >    At most one symbol may have the "modules" option set.
> >
> > +- phase declaration: "defphase"
> > +  This defines a new build phase. See `Build Phases`_.
> > +
> > +- default phase: "phasedefault"
> > +  This indicates the default build phase. See `Build Phases`_.
> > +
> > +- add entries for phases: "addphases"
> > +  This creates new phase-specific entries based on a template entry and
> adds
> > +  the same attributes to it. See `Build Phases`_.
> > +
> > +- set entries for phases: "setphases"
> > +  This sets the phases which need an entry. This allows creating an
> entry that
> > +  only has a primary phase. See `Build Phases`_.
> > +
> > +- indicate a phase-specific attribute: "forphases"
> > +  This marks an attribute as being applicable only to a particular
> phase or
> > +  group of phases.  See `Build Phases`_.
> > +
> >  Menu dependencies
> >  -----------------
> >
> > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this
> means it's only visible if
> >  MODULES is different from 'n'. The comment on the other hand is only
> >  visible when MODULES is set to 'n'.
> >
> > +Build Phases
> > +------------
> > +
> > +Some projects use Kconfig to control multiple build phases, each phase
> > +resulting in a separate set of object files and executable. This is the
> > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_.
> > +
> > +Generally the phases are related, so that enabling an entry in the
> primary
> > +phase also enables it by default in the others. But in some cases it may
> > +be desirable to use separate conditions for each phase.
> > +
> > +All phases have a phase name, for example `SPL`. This name is used as a
> > +prefix to each entry used in that phase, with an underscore in between.
> > +So if FOO is the primary entry, the equivalent entry for the SPL phase
> > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry.
> > +
> > +Phases are declared like any other menu entry except that also have a
> > +"defphase" keyword. Phase entries are normally hidden so do not have a
> > +prompt::
> > +
> > +    config PPL
> > +        bool
> > +        defphase "Primary Program Loader"
> > +        phasedefault
> > +        help
> > +          This is the primary bootloader.
> > +
> > +    config SPL
> > +        bool
> > +        defphase "Secondary Program Loader"
> > +        help
> > +          This is used to set up memory and load the primary bootloader.
> > +
> > +The default phase (here PPL) is assumed for all entries, in the sense
> that
> > +all entries are present in PPL by default and no prefix is needed on
> these
> > +entries. So FOO means that it applies to PPL. There must be exactly one
> > +default phase.
> > +
> > +The resulting menu entries can be used normally throughout the Kconfig.
> With
> > +this technique, the different build phases can be fully and individually
> > +controlled from Kconfig.
> > +
> > +However it is not ideal. Often the secondary phases have far fewer
> entries than
> > +the primary phase, since they offer fewer features. Even so, each FOO
> that is
> > +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of
> entries,
> > +it is possible to indicate which are enabled, as a shortcut for
> creating new
> > +entries::
> > +
> > +    config FOO
> > +        bool "Enable foo feature"
> > +        addphases SPL
> > +        depends on %BAR
> > +        depends on QUX
> > +        forphases SPL depends on FIZZ
> > +
> > +Note that "%" expands to the phase, so this is equivalent to (ignoring
> BAR)::
> > +
> > +    config FOO
> > +        bool "Enable foo feature"
> > +        depends on BAR
> > +        depends on QUX
> > +
> > +    config SPL_FOO                        # Phase is prepended
> > +        bool "Enable foo feature (SPL)"    # Suffix is added
> > +        depends on SPL_BAR                 # "%" dependency is expanded
> > +        depends on QUX
> > +        depends on FIZZ                    # Added only for SPL
> > +        depends on SPL                     # Added automatically
> > +
> > +Attributes declared in the primary symbol FOO (such as "depends on
> BAR") also
> > +apply to the secondary ones.
> > +
> > +An entry without any 'addphases' attribute applies to all phases.
> Individual
> > +phase entries are not available in that case. If the entry is enabled,
> then
> > +it is enabled for all phases. Only one entry appears in the resulting
> Kconfig.
> > +
> > +In the case where an entry should apply only to the primary phase (or a
> > +particular set of phases), you can uses "setphases" instead of
> "addphases"::
> > +
> > +    config FOO
> > +        bool "Enable foo feature"
> > +        setphases PPL
> > +
> > +This means that even if the option is enabled, it will not be active
> outside
> > +the primary-phase build, here named "PPL".
> > +
> > +Internally, phases are implemented simply by creating new entries. These
> > +appear in the Kconfig as per normal. It would be possible for a Kconfig
> > +editor to show the entries just for a particular phase, leaving out the
> > +entries not applicable to that phase.
> > +
> > +When phases are used, the Kconfig tool outputs separate auto.conf files
> for
> > +each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
> > +`CONFIG_FOO=y` is present in the file. This makes it easy for the build
> system
> > +to build the correct code, use IS_ENABLED(), etc.
> > +
> > +To ensure that the correct options are enabled for each build, in
> addition to
> > +the normal CONFIG_FOO option in the file, phase symbols are added too.
> For
> > +example, if FOO is enabled in the SPL phase, then auto_spl.conf
> contains::
> > +
> > +    CONFIG_FOO=y
> > +    CONFIG_SPL_FOO=y
> > +
> > +The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it
> allows one
> > +phase to access the symbols from another phase. For example, if the
> primary
> > +phase needs to receive boot timings from SPL, then support for boot
> timings must
> > +be added in both phases. If the timings are at a fixed address, this
> can be in a
> > +shared symbol (like CONFIG_SPL_TIMING_BASE) that both phases can access.
> > +
> > +Technical note: the grammar definition of <symbol> in this documeent
> does not
> > +include the "%" prefix at present. It can be used with any attribute.
> It cannot
> > +be used with any top-level items, like "config", "menuconfig", "if" and
> "menu".
> > +
> >
> >  Kconfig syntax
> >  --------------
> > @@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat
> >  .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
> >  .. [10] https://paulgazzillo.com/papers/esecfse21.pdf
> >  .. [11] https://github.com/paulgazz/kmax
> > +
> > +.. [12] https://u-boot.readthedocs.io/en/latest/develop/spl.html
> > +.. [13] https://docs.zephyrproject.org/latest/build/sysbuild/index.html
> > --
> > 2.39.2.637.g21b0678d19-goog
> >
>

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Masahiro Yamada]

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.

Masahiro










> On Fri, 24 Feb 2023 at 19:04, Simon Glass <sjg@chromium.org> wrote:
>>
>> +lk
>>
>> On Sun, 19 Feb 2023 at 14:55, Simon Glass <sjg@chromium.org> wrote:
>> >
>> > In the case of Linux, only one build is produced so there is only a
>> > single configuration. For other projects, such as U-Boot and Zephyr, the
>> > same code is used to produce multiple builds, each with related (but
>> > different) options enabled.
>> >
>> > This can be handled with the existing kconfig language, but it is quite
>> > verbose, somewhat tedious and very error-prone, since there is a lot of
>> > duplication. The result is hard to maintain.
>> >
>> > Describe an extension to the Kconfig language to support easier handling
>> > of this use case.
>> >
>> > Signed-off-by: Simon Glass <sjg@chromium.org>
>> > ---
>> >
>> >  Documentation/kbuild/kconfig-language.rst | 134 ++++++++++++++++++++++
>> >  1 file changed, 134 insertions(+)
>> >
>> > diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
>> > index 858ed5d80defe..73fb016a5533f 100644
>> > --- a/Documentation/kbuild/kconfig-language.rst
>> > +++ b/Documentation/kbuild/kconfig-language.rst
>> > @@ -228,6 +228,24 @@ applicable everywhere (see syntax).
>> >    enables the third modular state for all config symbols.
>> >    At most one symbol may have the "modules" option set.
>> >
>> > +- phase declaration: "defphase"
>> > +  This defines a new build phase. See `Build Phases`_.
>> > +
>> > +- default phase: "phasedefault"
>> > +  This indicates the default build phase. See `Build Phases`_.
>> > +
>> > +- add entries for phases: "addphases"
>> > +  This creates new phase-specific entries based on a template entry and adds
>> > +  the same attributes to it. See `Build Phases`_.
>> > +
>> > +- set entries for phases: "setphases"
>> > +  This sets the phases which need an entry. This allows creating an entry that
>> > +  only has a primary phase. See `Build Phases`_.
>> > +
>> > +- indicate a phase-specific attribute: "forphases"
>> > +  This marks an attribute as being applicable only to a particular phase or
>> > +  group of phases.  See `Build Phases`_.
>> > +
>> >  Menu dependencies
>> >  -----------------
>> >
>> > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means it's only visible if
>> >  MODULES is different from 'n'. The comment on the other hand is only
>> >  visible when MODULES is set to 'n'.
>> >
>> > +Build Phases
>> > +------------
>> > +
>> > +Some projects use Kconfig to control multiple build phases, each phase
>> > +resulting in a separate set of object files and executable. This is the
>> > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_.
>> > +
>> > +Generally the phases are related, so that enabling an entry in the primary
>> > +phase also enables it by default in the others. But in some cases it may
>> > +be desirable to use separate conditions for each phase.
>> > +
>> > +All phases have a phase name, for example `SPL`. This name is used as a
>> > +prefix to each entry used in that phase, with an underscore in between.
>> > +So if FOO is the primary entry, the equivalent entry for the SPL phase
>> > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry.
>> > +
>> > +Phases are declared like any other menu entry except that also have a
>> > +"defphase" keyword. Phase entries are normally hidden so do not have a
>> > +prompt::
>> > +
>> > +    config PPL
>> > +        bool
>> > +        defphase "Primary Program Loader"
>> > +        phasedefault
>> > +        help
>> > +          This is the primary bootloader.
>> > +
>> > +    config SPL
>> > +        bool
>> > +        defphase "Secondary Program Loader"
>> > +        help
>> > +          This is used to set up memory and load the primary bootloader.
>> > +
>> > +The default phase (here PPL) is assumed for all entries, in the sense that
>> > +all entries are present in PPL by default and no prefix is needed on these
>> > +entries. So FOO means that it applies to PPL. There must be exactly one
>> > +default phase.
>> > +
>> > +The resulting menu entries can be used normally throughout the Kconfig. With
>> > +this technique, the different build phases can be fully and individually
>> > +controlled from Kconfig.
>> > +
>> > +However it is not ideal. Often the secondary phases have far fewer entries than
>> > +the primary phase, since they offer fewer features. Even so, each FOO that is
>> > +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of entries,
>> > +it is possible to indicate which are enabled, as a shortcut for creating new
>> > +entries::
>> > +
>> > +    config FOO
>> > +        bool "Enable foo feature"
>> > +        addphases SPL
>> > +        depends on %BAR
>> > +        depends on QUX
>> > +        forphases SPL depends on FIZZ
>> > +
>> > +Note that "%" expands to the phase, so this is equivalent to (ignoring BAR)::
>> > +
>> > +    config FOO
>> > +        bool "Enable foo feature"
>> > +        depends on BAR
>> > +        depends on QUX
>> > +
>> > +    config SPL_FOO                        # Phase is prepended
>> > +        bool "Enable foo feature (SPL)"    # Suffix is added
>> > +        depends on SPL_BAR                 # "%" dependency is expanded
>> > +        depends on QUX
>> > +        depends on FIZZ                    # Added only for SPL
>> > +        depends on SPL                     # Added automatically
>> > +
>> > +Attributes declared in the primary symbol FOO (such as "depends on BAR") also
>> > +apply to the secondary ones.
>> > +
>> > +An entry without any 'addphases' attribute applies to all phases. Individual
>> > +phase entries are not available in that case. If the entry is enabled, then
>> > +it is enabled for all phases. Only one entry appears in the resulting Kconfig.
>> > +
>> > +In the case where an entry should apply only to the primary phase (or a
>> > +particular set of phases), you can uses "setphases" instead of "addphases"::
>> > +
>> > +    config FOO
>> > +        bool "Enable foo feature"
>> > +        setphases PPL
>> > +
>> > +This means that even if the option is enabled, it will not be active outside
>> > +the primary-phase build, here named "PPL".
>> > +
>> > +Internally, phases are implemented simply by creating new entries. These
>> > +appear in the Kconfig as per normal. It would be possible for a Kconfig
>> > +editor to show the entries just for a particular phase, leaving out the
>> > +entries not applicable to that phase.
>> > +
>> > +When phases are used, the Kconfig tool outputs separate auto.conf files for
>> > +each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
>> > +`CONFIG_FOO=y` is present in the file. This makes it easy for the build system
>> > +to build the correct code, use IS_ENABLED(), etc.
>> > +
>> > +To ensure that the correct options are enabled for each build, in addition to
>> > +the normal CONFIG_FOO option in the file, phase symbols are added too. For
>> > +example, if FOO is enabled in the SPL phase, then auto_spl.conf contains::
>> > +
>> > +    CONFIG_FOO=y
>> > +    CONFIG_SPL_FOO=y
>> > +
>> > +The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it allows one
>> > +phase to access the symbols from another phase. For example, if the primary
>> > +phase needs to receive boot timings from SPL, then support for boot timings must
>> > +be added in both phases. If the timings are at a fixed address, this can be in a
>> > +shared symbol (like CONFIG_SPL_TIMING_BASE) that both phases can access.
>> > +
>> > +Technical note: the grammar definition of <symbol> in this documeent does not
>> > +include the "%" prefix at present. It can be used with any attribute. It cannot
>> > +be used with any top-level items, like "config", "menuconfig", "if" and "menu".
>> > +
>> >
>> >  Kconfig syntax
>> >  --------------
>> > @@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat
>> >  .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
>> >  .. [10] https://paulgazzillo.com/papers/esecfse21.pdf
>> >  .. [11] https://github.com/paulgazz/kmax
>> > +
>> > +.. [12] https://u-boot.readthedocs.io/en/latest/develop/spl.html
>> > +.. [13] https://docs.zephyrproject.org/latest/build/sysbuild/index.html
>> > --
>> > 2.39.2.637.g21b0678d19-goog
>> >



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

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?

Regards,
Simon

>
>
> > On Fri, 24 Feb 2023 at 19:04, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> +lk
> >>
> >> On Sun, 19 Feb 2023 at 14:55, Simon Glass <sjg@chromium.org> wrote:
> >> >
> >> > In the case of Linux, only one build is produced so there is only a
> >> > single configuration. For other projects, such as U-Boot and Zephyr, the
> >> > same code is used to produce multiple builds, each with related (but
> >> > different) options enabled.
> >> >
> >> > This can be handled with the existing kconfig language, but it is quite
> >> > verbose, somewhat tedious and very error-prone, since there is a lot of
> >> > duplication. The result is hard to maintain.
> >> >
> >> > Describe an extension to the Kconfig language to support easier handling
> >> > of this use case.
> >> >
> >> > Signed-off-by: Simon Glass <sjg@chromium.org>
> >> > ---
> >> >
> >> >  Documentation/kbuild/kconfig-language.rst | 134 ++++++++++++++++++++++
> >> >  1 file changed, 134 insertions(+)
> >> >
> >> > diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> >> > index 858ed5d80defe..73fb016a5533f 100644
> >> > --- a/Documentation/kbuild/kconfig-language.rst
> >> > +++ b/Documentation/kbuild/kconfig-language.rst
> >> > @@ -228,6 +228,24 @@ applicable everywhere (see syntax).
> >> >    enables the third modular state for all config symbols.
> >> >    At most one symbol may have the "modules" option set.
> >> >
> >> > +- phase declaration: "defphase"
> >> > +  This defines a new build phase. See `Build Phases`_.
> >> > +
> >> > +- default phase: "phasedefault"
> >> > +  This indicates the default build phase. See `Build Phases`_.
> >> > +
> >> > +- add entries for phases: "addphases"
> >> > +  This creates new phase-specific entries based on a template entry and adds
> >> > +  the same attributes to it. See `Build Phases`_.
> >> > +
> >> > +- set entries for phases: "setphases"
> >> > +  This sets the phases which need an entry. This allows creating an entry that
> >> > +  only has a primary phase. See `Build Phases`_.
> >> > +
> >> > +- indicate a phase-specific attribute: "forphases"
> >> > +  This marks an attribute as being applicable only to a particular phase or
> >> > +  group of phases.  See `Build Phases`_.
> >> > +
> >> >  Menu dependencies
> >> >  -----------------
> >> >
> >> > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means it's only visible if
> >> >  MODULES is different from 'n'. The comment on the other hand is only
> >> >  visible when MODULES is set to 'n'.
> >> >
> >> > +Build Phases
> >> > +------------
> >> > +
> >> > +Some projects use Kconfig to control multiple build phases, each phase
> >> > +resulting in a separate set of object files and executable. This is the
> >> > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_.
> >> > +
> >> > +Generally the phases are related, so that enabling an entry in the primary
> >> > +phase also enables it by default in the others. But in some cases it may
> >> > +be desirable to use separate conditions for each phase.
> >> > +
> >> > +All phases have a phase name, for example `SPL`. This name is used as a
> >> > +prefix to each entry used in that phase, with an underscore in between.
> >> > +So if FOO is the primary entry, the equivalent entry for the SPL phase
> >> > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry.
> >> > +
> >> > +Phases are declared like any other menu entry except that also have a
> >> > +"defphase" keyword. Phase entries are normally hidden so do not have a
> >> > +prompt::
> >> > +
> >> > +    config PPL
> >> > +        bool
> >> > +        defphase "Primary Program Loader"
> >> > +        phasedefault
> >> > +        help
> >> > +          This is the primary bootloader.
> >> > +
> >> > +    config SPL
> >> > +        bool
> >> > +        defphase "Secondary Program Loader"
> >> > +        help
> >> > +          This is used to set up memory and load the primary bootloader.
> >> > +
> >> > +The default phase (here PPL) is assumed for all entries, in the sense that
> >> > +all entries are present in PPL by default and no prefix is needed on these
> >> > +entries. So FOO means that it applies to PPL. There must be exactly one
> >> > +default phase.
> >> > +
> >> > +The resulting menu entries can be used normally throughout the Kconfig. With
> >> > +this technique, the different build phases can be fully and individually
> >> > +controlled from Kconfig.
> >> > +
> >> > +However it is not ideal. Often the secondary phases have far fewer entries than
> >> > +the primary phase, since they offer fewer features. Even so, each FOO that is
> >> > +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of entries,
> >> > +it is possible to indicate which are enabled, as a shortcut for creating new
> >> > +entries::
> >> > +
> >> > +    config FOO
> >> > +        bool "Enable foo feature"
> >> > +        addphases SPL
> >> > +        depends on %BAR
> >> > +        depends on QUX
> >> > +        forphases SPL depends on FIZZ
> >> > +
> >> > +Note that "%" expands to the phase, so this is equivalent to (ignoring BAR)::
> >> > +
> >> > +    config FOO
> >> > +        bool "Enable foo feature"
> >> > +        depends on BAR
> >> > +        depends on QUX
> >> > +
> >> > +    config SPL_FOO                        # Phase is prepended
> >> > +        bool "Enable foo feature (SPL)"    # Suffix is added
> >> > +        depends on SPL_BAR                 # "%" dependency is expanded
> >> > +        depends on QUX
> >> > +        depends on FIZZ                    # Added only for SPL
> >> > +        depends on SPL                     # Added automatically
> >> > +
> >> > +Attributes declared in the primary symbol FOO (such as "depends on BAR") also
> >> > +apply to the secondary ones.
> >> > +
> >> > +An entry without any 'addphases' attribute applies to all phases. Individual
> >> > +phase entries are not available in that case. If the entry is enabled, then
> >> > +it is enabled for all phases. Only one entry appears in the resulting Kconfig.
> >> > +
> >> > +In the case where an entry should apply only to the primary phase (or a
> >> > +particular set of phases), you can uses "setphases" instead of "addphases"::
> >> > +
> >> > +    config FOO
> >> > +        bool "Enable foo feature"
> >> > +        setphases PPL
> >> > +
> >> > +This means that even if the option is enabled, it will not be active outside
> >> > +the primary-phase build, here named "PPL".
> >> > +
> >> > +Internally, phases are implemented simply by creating new entries. These
> >> > +appear in the Kconfig as per normal. It would be possible for a Kconfig
> >> > +editor to show the entries just for a particular phase, leaving out the
> >> > +entries not applicable to that phase.
> >> > +
> >> > +When phases are used, the Kconfig tool outputs separate auto.conf files for
> >> > +each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
> >> > +`CONFIG_FOO=y` is present in the file. This makes it easy for the build system
> >> > +to build the correct code, use IS_ENABLED(), etc.
> >> > +
> >> > +To ensure that the correct options are enabled for each build, in addition to
> >> > +the normal CONFIG_FOO option in the file, phase symbols are added too. For
> >> > +example, if FOO is enabled in the SPL phase, then auto_spl.conf contains::
> >> > +
> >> > +    CONFIG_FOO=y
> >> > +    CONFIG_SPL_FOO=y
> >> > +
> >> > +The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it allows one
> >> > +phase to access the symbols from another phase. For example, if the primary
> >> > +phase needs to receive boot timings from SPL, then support for boot timings must
> >> > +be added in both phases. If the timings are at a fixed address, this can be in a
> >> > +shared symbol (like CONFIG_SPL_TIMING_BASE) that both phases can access.
> >> > +
> >> > +Technical note: the grammar definition of <symbol> in this documeent does not
> >> > +include the "%" prefix at present. It can be used with any attribute. It cannot
> >> > +be used with any top-level items, like "config", "menuconfig", "if" and "menu".
> >> > +
> >> >
> >> >  Kconfig syntax
> >> >  --------------
> >> > @@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat
> >> >  .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
> >> >  .. [10] https://paulgazzillo.com/papers/esecfse21.pdf
> >> >  .. [11] https://github.com/paulgazz/kmax
> >> > +
> >> > +.. [12] https://u-boot.readthedocs.io/en/latest/develop/spl.html
> >> > +.. [13] https://docs.zephyrproject.org/latest/build/sysbuild/index.html
> >> > --
> >> > 2.39.2.637.g21b0678d19-goog
> >> >
>
>
>
> --
> Best Regards
> Masahiro Yamada

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Masahiro Yamada]

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.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Masahiro Yamada]

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.

Kconfig has small piece of code that is useful for other projects,
for example,

    #ifndef CONFIG_
    #define CONFIG_ "CONFIG_"
    #endif

which might be useful for Buildroot, but this is exceptionally small.


The multi-phase is too cluttered, and that is not what Linux wants to have.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

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_"
>     #endif
>
> which 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.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-sjg@chromium.org/

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Masahiro Yamada]

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.





> >
> > Kconfig has small piece of code that is useful for other projects,
> > for example,
> >
> >     #ifndef CONFIG_
> >     #define CONFIG_ "CONFIG_"
> >     #endif
> >
> > which 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?


Code refactoring is welcome, but [1] is not applicable.
U-Boot kconfig is synced with Linux 4.20, way behind the mainline Linux.





> >
> >
> > 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.
>
> Regards,
> Simon
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-sjg@chromium.org/



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Simon Glass]

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?

> > >
> > > Kconfig has small piece of code that is useful for other projects,
> > > for example,
> > >
> > >     #ifndef CONFIG_
> > >     #define CONFIG_ "CONFIG_"
> > >     #endif
> > >
> > > which 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?
>
>
> Code refactoring is welcome, but [1] is not applicable.
> U-Boot kconfig is synced with Linux 4.20, way behind the mainline Linux.

Sure, I wasn't suggesting that exact patch. It should be easy enough
to move to the latest version. It sounds like it may be possible to
make the Frankenstein patches easier to maintain out of tree, if we go
that way.

> > >
> > >
> > > 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.
> >
> > [1] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-sjg@chromium.org/

Regards,
Simon

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Masahiro Yamada]

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.
It was not designed with multi-phase images in mind.


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.

This is a U-Boot-specific problem.
Please solve it in U-Boot.


Masahiro Yamada






>
> > > >
> > > > Kconfig has small piece of code that is useful for other projects,
> > > > for example,
> > > >
> > > >     #ifndef CONFIG_
> > > >     #define CONFIG_ "CONFIG_"
> > > >     #endif
> > > >
> > > > which 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?
> >
> >
> > Code refactoring is welcome, but [1] is not applicable.
> > U-Boot kconfig is synced with Linux 4.20, way behind the mainline Linux.
>
> Sure, I wasn't suggesting that exact patch. It should be easy enough
> to move to the latest version. It sounds like it may be possible to
> make the Frankenstein patches easier to maintain out of tree, if we go
> that way.
>
> > > >
> > > >
> > > > 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.
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-sjg@chromium.org/
>
> Regards,
> Simon


--
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

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_"
> >     #endif
> >
> > which 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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] kconfig: Proposed language extension for multiple builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5455 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]