Re: [PATCH v7 00/11] kconfig: Add support for conflict resolution

[Luis Chamberlain <mcgrof@kernel.org>]

+ kdevops

On Mon, Mar 03, 2025 at 01:56:44AM +0900, Masahiro Yamada wrote:
> On Fri, Feb 21, 2025 at 12:03 PM Jude Gyimah
> <Jude.Gyimah@ruhr-uni-bochum.de> 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.

Jude, while Masahiro works on dynamic shell evaluation support and
given the SAT solver currently works with bools / tristates, I can
think of ways we can likely move forward to experiment with the existing
SAT solver integration, and can think of ways we can get ahead by
exploring ways to leverage the SAT solver on kdevops which can likely
pave the way for its use also later in Linux.

We already carry a small delta on our kdevops kconfig to support yaml
output which has proven invaluable to us, we can carry a SAT solver, as
things settle with dynamic shell evaluation on Linux.

How can we leverage a SAT solver on kdevops?

1) Feature-driven configuration and scriptable goals

Instead of having the user do the heavy work on figuring out what the
heck to enable on make menuconfig, the user just has to writes a
requirement. Something like this:

ci-goal:
  - filesystem: xfs
  - features: [reflink, 4k]
  - workload: sysbench-mysql-docker

This can also enable scriptable CI goals:

kconfig-solve --enable sysbench --fs xfs --blocksize 4k --reflink

Generates .config to let us test this.

2) Minimized configs to reproduce a test on our CI

Today if someone wants to reproduce a generic/750 test on xfs reflink 4k
profile they can just use the web interface to select just the xfs_reflink_4k
defconfig, and we have a kconfig option to let us limit the test to a
set specified [0]. That requires adding a defconfig per test profile we
support. Wouldn't it be nicer if we can just say:

ci-goal:
  - filesystem: xfs
  - features: [reflink, 4k]
  - testsuite: fstests
  - tests: generic/750

3) Generate a set of different tests for a goal

Given a set of features we want to test, we could have the
SAT solver look for satisfiable combinations we could have

ci-goal:
  - filesystem: xfs
  - features: [reflink]
  - workload: sysbench-mysql-docker

And so this may generate different .configs to help us run each one as a
setup to test test XFS on mysql using docker using all XFS profiles.

Let me know if your team is interested in exploring these things.

[0] https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/linux-filesystems-kdevops-CI-testing.md

  Luis