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

[Luis Chamberlain <mcgrof@kernel.org>]

On Thu, Aug 21, 2025 at 11:35:11AM +0200, Daniel Gomez wrote:
> On 04/07/2025 04.26, Daniel Gomez wrote:
> > From: Daniel Gomez <da.gomez@samsung.com>
> > 
> > Introduce a params.mk file for user-defined Makefile parameters.
> > Users can refer to params.mk.sample to see the available configuration
> > options and create their own params.mk accordingly. When enabled via
> > Kconfig, a params.mk will be automatically generated at the specified
> > directory using the sample as a template. When enabled,
> > Makefile will attempt to include params.mk if it exists.
> > 
> > Example: Enable Makefile verbosity and Ansible Verbosity Level 4.
> > 
> > File: params.mk
> > 
> > V = 1
> > AV = 4
> > 
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> > We use GNU Make as a wrapper mainly for Kconfig and Ansible. In order
> > to assist kdevops users to change certain options we expose certain
> > features to the cli interface via Makefile parameters. A few examples
> > are the verbosity of the ansible-playbook command (-v, -vv...) via AV
> > parameter. Or the Linux tree git reference (Kconfig) to be used via
> > LINUX_TREE_REF. This seems convenient and has been increasing over time.
> > Enough parameters have been added than I personally tend to forget
> > the exact variable/argument/parameter names. For that, documentation
> > may be best but when using a large combination of these options, the
> > cli becomes inconvenient by itself. To help with command cli parameters,
> > this patch adds a file params.mk.sample that will generate a params.mk
> > (if it doesn't exist already) with all parameters disabled. But the file
> > will contain examples of how to use each of the options available via
> > cli interface. The main Makefile will parse this first and will make it
> > available as if the user would pass them through the command line making
> > it easier to handle, specially when multiple options are used.
> > 
> > Thoughts?
> 
> I want to revive this thread to suggest another direction. I've noticed the
> script/config from Linux was actually merged by Chuck with commit 9b2b75c4c3d0
> "scripts: Copy scripts/config from the Linux kernel repo". This script allows to
> customize the Kconfig options via cli without the need of using make.
> 
> For example, I can run this:
> make defconfig-seltests-xarray
> grep FORKS= .config
> CONFIG_ANSIBLE_CFG_FORKS=10
> ./scripts/config --set-val ANSIBLE_CFG_FORKS 12
> CONFIG_ANSIBLE_CFG_FORKS=12
> 
> So, what if we drop support for all current CLI options and allow users to
> leverage individual Kconfig options instead? 

I can see you wanting to use the config script, but I don't see a reason
to drop it. The CLI stuff is not only useful for setting config stuff
up at initialization but also at runtime on Makefiles like:

   make fstests-tests TESTS=generic/750

Also, I don't see a stated reason to remove the CLI stuff.

> Using the above config, the CLI now
> supports all Kconfig options instead of a subset.
> 
> Now, I think the config script just needs to trigger the YAML output generation
> path so .extra_vars_auto.yaml and extra_vars.yaml are generated accordingly to
> the new user option.


Let's think more long term. The config script is a hack really, its not
deterministic, and the real long term solution to all this is a SAT
solver on kconfig so you can later request input requirements to get
your deterministic desriable .config.

> Reviewing what the current cli supports, I think the only non-kconfig options
> are:

I'm adding more like some quick tests options to reduce the time it
takes to test some tests (fio-tests, and some AI stuff in my pipeline).

I can see the desire to bring forward the mergeconfig stuff, I just see
a stated reason why remove the CLI stuff.

  Luis