Re: [PATCH] Makefile: Add support for user makefile params

[Luis Chamberlain <mcgrof@kernel.org>]

On Mon, Aug 25, 2025 at 10:01:19AM +0200, Daniel Gomez wrote:
> So, a possible solution to all this is:
> * Keep the CLI options to bypass config step
> * Add all CLI variables/parameters to the help menu. This is to have
> documentation and replace the params.mk suggested in this patch
> * Expose all CLI options to kconfig to be consistent with both paths. For example,
> I think kconfig is missing TESTS support
> 

Sure.

> My understanding is that Kconfig does not have a way to solve deterministically
> dependencies for a given config. For that, we need to be specific with the
> requirements. And that is what the script/config and fragment enables. I don't
> recall exactly the details of SAT solver [2], but looks similar to Kconfig
> fragments but in a YAML syntax.

No, a SAT solver is a real solution. config.sh is a hack. What we want
to do is to help start paving the way for a SAT solver use cases,
testing is a good use case, then Linux can start adopting it as well,
and later we can perhaps use it in actual code.

Fragments are just a desirable outcome, think more about leveraging yaml
for requirements, and then having a SAT solver give you a real .config
for you.

Fragments are just a hack then.

A SAT solver integration is what you want.

> Regarding mergeconfig and SAT solvers, I believe the mergeconfig script already
> gives users the benefits of a SAT solver, just with fragments and files instead
> of YAML. From your suggestion in the SAT solver thread, the fragments are a bit
> more complex. But not more that current kernel configs.

mergeconfig is just what we have today, however its not rock solid. So
sure, its fine today to use, but I figured I'd share with you a long
term road map.

> My proposal for that would be to integrate mergeconfig to provide early SAT
> solver support.

mergeconfig has nothing to do with a SAT solver.

A SAT solver is a serious piece of software. mergconfig is a hack.

> And for long term solution, transition Kconfig to read YAML
> directly, rather than relying on fragments or configs. And drop support to
> defconfigs format to be YAML as well.

Right.

FWIW, I've been thinking about this for years:

https://kernelnewbies.org/KernelProjects/kconfig-sat

Since we have patches available for SAT solver integration into kconfig
now posted [0], we can just fast foward and integrate them if we want to.

[0] https://lkml.kernel.org/r/20250208163959.3973163-1-ole0811sch@gmail.com

  Luis