MIME-Version: 1.0
References: <20230219145453.1.Idaaf79c3e768b85750d5a7eb732052576c5e07e5@changeid>
 <CAPnjgZ0BxS3CHKzofGE1SbAZouhMakAU_KUmfpy_OmJTkzyhSA@mail.gmail.com> <CAPnjgZ3xpoJ33fgSG589E+xoUk4-dVbhwadfo+sd=hxqF-z0Vg@mail.gmail.com>
In-Reply-To: <CAPnjgZ3xpoJ33fgSG589E+xoUk4-dVbhwadfo+sd=hxqF-z0Vg@mail.gmail.com>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun, 26 Feb 2023 12:31:00 +0900
Message-ID: <CAK7LNAT=tmXdJahjdXBrj8ASmEDhdeeqbXfSdyXCzkJZgix+Hg@mail.gmail.com>
Subject: Re: [PATCH] kconfig: Proposed language extension for multiple builds
To:     Simon Glass <sjg@chromium.org>
Cc:     U-Boot Mailing List <u-boot@lists.denx.de>,
        lk <linux-kernel@vger.kernel.org>, Tom Rini <trini@konsulko.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, Feb 25, 2023 at 11:38=E2=80=AFAM Simon Glass <sjg@chromium.org> wro=
te:
>
> +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, t=
he
>> > 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 quit=
e
>> > verbose, somewhat tedious and very error-prone, since there is a lot o=
f
>> > duplication. The result is hard to maintain.
>> >
>> > Describe an extension to the Kconfig language to support easier handli=
ng
>> > 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 a=
nd 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 e=
ntry 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 ph=
ase or
>> > +  group of phases.  See `Build Phases`_.
>> > +
>> >  Menu dependencies
>> >  -----------------
>> >
>> > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this me=
ans 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 phas=
e
>> > +resulting in a separate set of object files and executable. This is t=
he
>> > +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 pr=
imary
>> > +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 betwee=
n.
>> > +So if FOO is the primary entry, the equivalent entry for the SPL phas=
e
>> > +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 bootload=
er.
>> > +
>> > +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 o=
ne
>> > +default phase.
>> > +
>> > +The resulting menu entries can be used normally throughout the Kconfi=
g. With
>> > +this technique, the different build phases can be fully and individua=
lly
>> > +controlled from Kconfig.
>> > +
>> > +However it is not ideal. Often the secondary phases have far fewer en=
tries 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 creat=
ing 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 (ignorin=
g 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 expand=
ed
>> > +        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 BA=
R") also
>> > +apply to the secondary ones.
>> > +
>> > +An entry without any 'addphases' attribute applies to all phases. Ind=
ividual
>> > +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 "addph=
ases"::
>> > +
>> > +    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. Th=
ese
>> > +appear in the Kconfig as per normal. It would be possible for a Kconf=
ig
>> > +editor to show the entries just for a particular phase, leaving out t=
he
>> > +entries not applicable to that phase.
>> > +
>> > +When phases are used, the Kconfig tool outputs separate auto.conf fil=
es for
>> > +each phase (e.g. auto_spl.conf), so that if SPL_FOO is enabled, then
>> > +`CONFIG_FOO=3Dy` is present in the file. This makes it easy for the b=
uild system
>> > +to build the correct code, use IS_ENABLED(), etc.
>> > +
>> > +To ensure that the correct options are enabled for each build, in add=
ition 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 conta=
ins::
>> > +
>> > +    CONFIG_FOO=3Dy
>> > +    CONFIG_SPL_FOO=3Dy
>> > +
>> > +The phase-specific line (CONFIG_SPL_FOO) is seldom needed, but it all=
ows one
>> > +phase to access the symbols from another phase. For example, if the p=
rimary
>> > +phase needs to receive boot timings from SPL, then support for boot t=
imings 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 acce=
ss.
>> > +
>> > +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" a=
nd "menu".
>> > +
>> >
>> >  Kconfig syntax
>> >  --------------
>> > @@ -744,3 +875,6 @@ https://kernelnewbies.org/KernelProjects/kconfig-s=
at
>> >  .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pd=
f
>> >  .. [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.ht=
ml
>> > --
>> > 2.39.2.637.g21b0678d19-goog
>> >


--=20
Best Regards
Masahiro Yamada