On Fri, Feb 21, 2025 at 12:03 PM Jude Gyimah <Jude.Gyimah@xxxxxxxxxxxxxxxxxx> wrote: > > Quick follow-up. > > On our end, our SAT-solver implementations can be easily adapted to accommodate your future > toolchain selection refactorings. OK, we will see. > > Also, could you share with us the timelines for your refactorings so we can plan and deliver the > adjusted SAT-solver patches. There is no timeline in upstream development. > Best Regards, > Jude Gyimah > > On 2/11/25 01:46, Masahiro Yamada wrote: > > On Tue, Feb 11, 2025 at 12:43 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> 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
