Date:   Sat, 11 Mar 2023 11:55:07 -0500
From:   Tom Rini <trini@konsulko.com>
To:     Randy Dunlap <rdunlap@infradead.org>
Cc:     Simon Glass <sjg@chromium.org>,
        LKML <linux-kernel@vger.kernel.org>,
        U-Boot Custodians <u-boot-custodians@lists.denx.de>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        barebox@lists.infradead.org, Sascha Hauer <s.hauer@pengutronix.de>,
        U-Boot Mailing List <u-boot@lists.denx.de>,
        Jonathan Corbet <corbet@lwn.net>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Nicolas Schier <nicolas@fjasle.eu>, linux-doc@vger.kernel.org,
        linux-kbuild@vger.kernel.org
Subject: Re: [RESEND PATCH] kconfig: Proposed language extension for multiple
 builds
Message-ID: <20230311165507.GN3041508@bill-the-cat>
References: <20230310183717.RESEND.1.Idaaf79c3e768b85750d5a7eb732052576c5e07e5@changeid>
 <bae2702e-3570-f461-b86f-e56ce82a636e@infradead.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="nKkts6aBvDQ9fwd+"
Content-Disposition: inline
In-Reply-To: <bae2702e-3570-f461-b86f-e56ce82a636e@infradead.org>
Precedence: bulk


--nKkts6aBvDQ9fwd+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 10, 2023 at 09:39:15PM -0800, Randy Dunlap wrote:
> Hi--
>=20
> On 3/10/23 18:37, Simon Glass wrote:
> > (I am sending this again to get more feedback)
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > Describe an extension to the Kconfig language to support easier handling
> > of this use case.
> >=20
> > Signed-off-by: Simon Glass <sjg@chromium.org>
>=20
> IMO Masahiro has already answered this multiple times and I agree with hi=
s answers.
>=20
> For others, the full previous thread is at
>   https://lore.kernel.org/all/20230219145453.1.Idaaf79c3e768b85750d5a7eb7=
32052576c5e07e5@changeid/

Well, I think what was unclear, or maybe we just wanted to confirm the
answer was "none at all", was this. As good community neighbors, we see
a generic issue in the Kconfig language, a tool used frequently outside
of just the Linux kernel, and would like to contribute back. Ideally
without having first gone off, designed and implemented something, and
then been told it's all wrong and to rewrite it first. So what level of
interest is there in this?

As I pointed out in that thread, I believe barebox has examples where
some keyword like we're proposing here would help them (and yes, there's
only a dozen or so symbols so it's also manageable without anything
special), and Simon believes Zephyr will be in a similar situation soon
enough (which doesn't use the kernel's implementation of the language).
Frankly, I keep going back to "tristate" is just the original example of
what we're talking about here (CONFIG_FOO=3Dn, CONFIG_FOO_MODULE=3Dy), not
that I'm suggesting we would remove the tristate word.
So we would really like to make sure as many people and projects are
aware, as possible.

And as Simon asked in the thread, what about code refactoring that makes
further maintenance easier? Clearly, such patches would need to be
against the current appropriate tree.

--=20
Tom

--nKkts6aBvDQ9fwd+
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmQMsmcACgkQFHw5/5Y0
tyx+wwv/dmFZaZi7VhdtJ2VaNC4i1XByc8cyBYW3rT8yVRK75dzQ9I/p0FGL8LCx
73GpQdSlx+n8S+qPu3d71WUpv5dZBBdqSjD6s4olHY3p+xuriV9Qd1UM9qiEyYXf
sQH+bVlvK+82C3xADqUiKdgTzKqMKxW2zhUj88qTIHxKpdbzF/7Y7TnuMLH3sAhP
Ho8dpmM+PKxL0J4i9aMX664hpwU7I4yDBnc0oXa2ROgRdogu0yKt+6TGecs9qsL2
IUnl9Cp8x6EtFVQd2otm/UUAQrbyGBW+WZDVWcuS99Bs0bGi1Bl7B+IBsP8JOmD0
jlMcn/IJlo1b7cAKri8mlPGBEXtIcthBJ/TYPmx/MwmG9Oj0WjQPLsfYVuppb/bu
7i2nHzVRl3+UBWMppuyrsUROhBBdlBEqPJRZJhCHEfHa6kKGucClIoqM7RqmOxtC
dOSQrs/XyC9gCJ4TUDep5eSiNizYzpl14QcJpxv+iQu86W96tWE5fc4Q4zZSEl5m
YzXxsFiQ
=OI2Z
-----END PGP SIGNATURE-----

--nKkts6aBvDQ9fwd+--