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

[Daniel Gomez <da.gomez@kernel.org>]

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? 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.

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

* V -> controls Makefile commands verbosity. We can expose this to Kconfig
option. We may lose initial verbosity before the new option is parsed. I think
it's fine as we can always overwrite Makefile variables in cli anyways. My point
is to be able to control it via Kconfig.

* AV -> controls ansible-playbook verbosity control. This can be moved from the
command line wrapper to the ansible.cfg using the verbosity key [1]

* HOSTS -> controls ansible-playbook --limit argument. This can be moved to it's
own limit file autogenerated using '--limit @file' [2] + Kconfig option.

* START_AFTER -> controls a YAML variable. We simply expose this to Kconfig

* TESTS -> controls LIMIT_TESTS and a YAML variable. Same as START_AFTER, we
expose this to Kconfig

* CI_WORKFLOW -> it's a Makefile variable. Same as START_AFTER and TESTS, we
can expose this to Kconfig as well

In summary, with these changes applied, the CLI parameters would no longer be
supported. Instead, users would follow this workflow (for example):

make defconfig-seltests-xarray
./scripts/config --set-val ANSIBLE_CFG_FORKS 12
./scripts/config --set-val ANSIBLE_VERBOSITY 2
./scripts/config --enable MAKEFILE_VERBOSITY
./scripts/config --set-val LIBVIRT_IMAGE_SIZE 40
./scripts/config --enable LIBVIRT_MEM_8G
./scripts/config --set-val BOOTLINUX_TREE_REF v6.12

make && make bringup && \
make selftests && make selftests-baseline && make selftests-results

Note: You can combine these --set-val/enable options in one long command or in a
fragment file if we merge the merge_config.sh script from Linux upstream. Here's
how I use it for my kernel builds [3]. With that, I'd put all the options above
in dani.config and run:
./scripts/kconfig/merge_config.sh -n .config dani.config

For fstests workflow and the TESTS, START_AFTER, etc being exposed to Kconfig,
users would do:
./scripts/config --set-val FSTESTS_TESTS "generic/531 xfs/008 xfs/013"

or:
./scripts/config --set-val FSTESTS_START_AFTER "generic/451"
make fstests-baseline

Link: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-verbosity [1]
Link: https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html#patterns-and-ansible-playbook-flags [2]
Link: https://github.com/dkruces/linux-config-fragments?tab=readme-ov-file#using-merge-config [3]

Thoughts?