[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNAT48101gZzcHF3U-VL1i0Ekns6zXKpNDb3MnScoSNr-kw@mail.gmail.com>
Date: Tue, 11 Feb 2025 09:46:36 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Ole Schuerks <ole0811sch@...il.com>, linux-kbuild@...r.kernel.org, jude.gyimah@....de,
thorsten.berger@....de, deltaone@...ian.org, jan.sollmann@....de,
linux-kernel@...r.kernel.org, nathan@...nel.org, nicolas@...sle.eu
Subject: Re: [PATCH v7 00/11] kconfig: Add support for conflict resolution
On Tue, Feb 11, 2025 at 12:43 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> On Mon, Feb 10, 2025 at 02:00:52PM +0900, Masahiro Yamada wrote:
> > Thanks for this, but I have no plans to merge the SAT solver.
> >
> > The reason is that my future plan is to move toolchain selection
> > to the Kconfig stage instead of specifying it statically from the command line.
>
> That makes sense.
>
> > This approach was suggested by Linus [1], and to achieve that,
> > the shell evaluation must be dynamically re-evaluated [2].
>
> Sure.
>
> > The SAT solver would likely conflict with this plan. At least due to the
> > significant amount of additional code, which would be an obstacle.
>
> I can't see how the toolchain selection, if set on Kconfig can't be
> leveraged later to enable / disable the SAT solver, however I can
> see the amount of code shuffling incurred to be an extra hurdle to
> address and a preference to leave that for later.
>
> In other words, I susepct it is still possible to evaluate to
> add support for the SAT solver post toolchain kconfig integration.
>
> Thoughts?
It depends on how the dynamic shell evaluation is implemented.
This is not limited to bool/tristate, but SAT solver only works for
those two types.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists