[PATCH] Makefile: Add support for user makefile params

[PATCH] Makefile: Add support for user makefile params

[Daniel Gomez]

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?
---
 .gitignore               |  2 ++
 Makefile                 |  8 ++++++++
 kconfigs/Kconfig.kdevops | 14 ++++++++++++++
 params.mk.sample         | 44 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 68 insertions(+)

diff --git a/.gitignore b/.gitignore
index 706ef3f..470ac24 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,6 +5,8 @@
 .kdevops\.depcheck
 .provisioned_once*
 
+params.mk
+
 guestfs/
 !playbooks/roles/guestfs/
 
diff --git a/Makefile b/Makefile
index acbdd1a..0cbcc09 100644
--- a/Makefile
+++ b/Makefile
@@ -32,6 +32,11 @@ export ANSIBLE_CONFIG := $(ANSIBLE_CFG_FILE)
 endif
 ANSIBLE_INVENTORY_FILE := $(shell echo $(CONFIG_ANSIBLE_CFG_INVENTORY) | tr --delete '"')
 
+ifeq (y,$(CONFIG_ENABLE_KDEVOPS_PARAMS))
+KDEVOPS_PARAMS := $(shell echo $(CONFIG_KDEVOPS_PARAMS) | tr --delete '"')
+-include $(KDEVOPS_PARAMS)
+endif
+
 KDEVOPS_INSTALL_TARGETS :=
 
 DEFAULT_DEPS :=
@@ -204,6 +209,9 @@ $(ANSIBLE_CFG_FILE): .config
 		$(KDEVOPS_PLAYBOOKS_DIR)/ansible_cfg.yml \
 		--extra-vars=@./.extra_vars_auto.yaml
 
+$(KDEVOPS_PARAMS):
+	$(Q)cp --verbose $(TOPDIR_PATH)/params.mk.sample $(KDEVOPS_PARAMS)
+
 PHONY += $(EXTRA_VAR_INPUTS) $(EXTRA_VAR_INPUTS_LAST)
 
 $(KDEVOPS_EXTRA_VARS): .config $(EXTRA_VAR_INPUTS) $(EXTRA_VAR_INPUTS_LAST)
diff --git a/kconfigs/Kconfig.kdevops b/kconfigs/Kconfig.kdevops
index 35e9758..4d58261 100644
--- a/kconfigs/Kconfig.kdevops
+++ b/kconfigs/Kconfig.kdevops
@@ -199,3 +199,17 @@ endmenu
 menu "Ansible Configuration"
 source "kconfigs/Kconfig.ansible_cfg"
 endmenu
+
+config ENABLE_KDEVOPS_PARAMS
+	bool "Enable Kdevops User Makefile Parameters File"
+	default y
+
+if ENABLE_KDEVOPS_PARAMS
+
+config KDEVOPS_PARAMS
+	string "Enable Makefile Parameters File"
+	default "$(TOPDIR_PATH)/params.mk"
+	help
+	  Create user params.mk
+
+endif # ENABLE_KDEVOPS_PARAMS
diff --git a/params.mk.sample b/params.mk.sample
new file mode 100644
index 0000000..2afae8f
--- /dev/null
+++ b/params.mk.sample
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: copyleft-next-0.3.1
+#
+# [ Makefile Parameters ]
+#
+# Enable Makefile Verbosity
+# V = 1
+#
+# Configure Ansible Verbosity Level (V = {1..6})
+# AV = 1
+#
+# Run command on defined targets
+# HOSTS="host1 host2"
+#
+# [ Ansible Configuration ]
+#
+# ANSIBLE_CFG_CALLBACK_PLUGIN = "dense"
+# ANSIBLE_CFG_INTERPRETER_PYTHON = "/usr/bin/env python3"
+# ANSIBLE_CFG_FORKS = "5"
+# KDEVOPS_HOSTS = "$(TOPDIR_PATH)/hosts"
+#
+# [ Workflows ]
+#
+# KDEVOPS_HOSTS_PREFIX = "kdevops"
+#
+# [ Workflow: fstests ]
+#
+# Running fstests against only a set of tests
+# TESTS = "generic/531 xfs/008 xfs/013"
+#
+# Running fstests from a specific starting point
+# START_AFTER = "generic/451"
+#
+# SOAK_DURATION = ""
+# FSTESTS_GROUP = ""
+#
+# [ Workflow: linux ]
+#
+# LINUX_TREE = ""
+# LINUX_TREE_REF = ""
+# B4_MESSAGE_ID = ""
+#
+# [ Workflows: CI ]
+#
+# CI_WORKFLOW = "blktests_block"

---
base-commit: 4d8e5043bf64d51fe391245d1526c1c65617e437
change-id: 20250704-b4-params-1b98406cbbea
prerequisite-change-id: 20250430-ansible_cfg_inventory-7955944ce8ff:v4
prerequisite-patch-id: a6c8585cae96f5a44064b18d68113d6bb9e36584
prerequisite-patch-id: e27d48a419b82a0fa1af06d78da315c9ef36c8b8
prerequisite-patch-id: 87405487f3863f93b623f391d46333fb50b9c148
prerequisite-patch-id: c628eed9f004f0d494a7fc028bc2c1398da511e5
prerequisite-patch-id: 95108ed1160cfe3bcc87f141e0508efc2c08cf47
prerequisite-patch-id: 5962dc6100eae5658513ef88c22175988763aa4b
prerequisite-patch-id: 19a992e90eed8faa04f20d122d4d3d5a51f2ea77
prerequisite-patch-id: db660adc9266da83e6dad6d4df59ecd7538b32bb
prerequisite-patch-id: 5f05abf3975b5e8168ac56b8a3ce1c9b2eacf41d
prerequisite-patch-id: 0eb292f5292f2748fcc794c91ec978c8816c4ffc
prerequisite-patch-id: ecad3ea874604b00af65ed08c65368db0d95f1c0

Best regards,
--  
Daniel Gomez <da.gomez@samsung.com>

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

[Chuck Lever]

On 7/4/25 7:26 AM, 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?

Why is a new Kconfig option needed? Instead, can the param.mk file
either exist or not, and "make" will work either way?


I'm glad to see the comments documenting each variable in the sample
file. Some of these I did not know about before. Are they documented
somewhere else as well? Having them all in one place is great.

But, the use of "[ section name ]" suggests this file might be an
INI file, though it's actually just "VAR = value" with comments. A
block comment at the top that explains the format would be helpful,
and perhaps find a different way of demarcating the sections.

/etc/ssh/ssh_config, for example, has this:

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

The head of /etc/dnsmasq.conf looks like this:

# Configuration file for dnsmasq.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.


> ---
>  .gitignore               |  2 ++
>  Makefile                 |  8 ++++++++
>  kconfigs/Kconfig.kdevops | 14 ++++++++++++++
>  params.mk.sample         | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 68 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 706ef3f..470ac24 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -5,6 +5,8 @@
>  .kdevops\.depcheck
>  .provisioned_once*
>  
> +params.mk
> +
>  guestfs/
>  !playbooks/roles/guestfs/
>  
> diff --git a/Makefile b/Makefile
> index acbdd1a..0cbcc09 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -32,6 +32,11 @@ export ANSIBLE_CONFIG := $(ANSIBLE_CFG_FILE)
>  endif
>  ANSIBLE_INVENTORY_FILE := $(shell echo $(CONFIG_ANSIBLE_CFG_INVENTORY) | tr --delete '"')
>  
> +ifeq (y,$(CONFIG_ENABLE_KDEVOPS_PARAMS))
> +KDEVOPS_PARAMS := $(shell echo $(CONFIG_KDEVOPS_PARAMS) | tr --delete '"')
> +-include $(KDEVOPS_PARAMS)
> +endif
> +
>  KDEVOPS_INSTALL_TARGETS :=
>  
>  DEFAULT_DEPS :=
> @@ -204,6 +209,9 @@ $(ANSIBLE_CFG_FILE): .config
>  		$(KDEVOPS_PLAYBOOKS_DIR)/ansible_cfg.yml \
>  		--extra-vars=@./.extra_vars_auto.yaml
>  
> +$(KDEVOPS_PARAMS):
> +	$(Q)cp --verbose $(TOPDIR_PATH)/params.mk.sample $(KDEVOPS_PARAMS)
> +
>  PHONY += $(EXTRA_VAR_INPUTS) $(EXTRA_VAR_INPUTS_LAST)
>  
>  $(KDEVOPS_EXTRA_VARS): .config $(EXTRA_VAR_INPUTS) $(EXTRA_VAR_INPUTS_LAST)
> diff --git a/kconfigs/Kconfig.kdevops b/kconfigs/Kconfig.kdevops
> index 35e9758..4d58261 100644
> --- a/kconfigs/Kconfig.kdevops
> +++ b/kconfigs/Kconfig.kdevops
> @@ -199,3 +199,17 @@ endmenu
>  menu "Ansible Configuration"
>  source "kconfigs/Kconfig.ansible_cfg"
>  endmenu
> +
> +config ENABLE_KDEVOPS_PARAMS
> +	bool "Enable Kdevops User Makefile Parameters File"
> +	default y
> +
> +if ENABLE_KDEVOPS_PARAMS
> +
> +config KDEVOPS_PARAMS
> +	string "Enable Makefile Parameters File"
> +	default "$(TOPDIR_PATH)/params.mk"
> +	help
> +	  Create user params.mk
> +
> +endif # ENABLE_KDEVOPS_PARAMS
> diff --git a/params.mk.sample b/params.mk.sample
> new file mode 100644
> index 0000000..2afae8f
> --- /dev/null
> +++ b/params.mk.sample
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: copyleft-next-0.3.1
> +#
> +# [ Makefile Parameters ]
> +#
> +# Enable Makefile Verbosity
> +# V = 1
> +#
> +# Configure Ansible Verbosity Level (V = {1..6})
> +# AV = 1
> +#
> +# Run command on defined targets
> +# HOSTS="host1 host2"
> +#
> +# [ Ansible Configuration ]
> +#
> +# ANSIBLE_CFG_CALLBACK_PLUGIN = "dense"
> +# ANSIBLE_CFG_INTERPRETER_PYTHON = "/usr/bin/env python3"
> +# ANSIBLE_CFG_FORKS = "5"
> +# KDEVOPS_HOSTS = "$(TOPDIR_PATH)/hosts"
> +#
> +# [ Workflows ]
> +#
> +# KDEVOPS_HOSTS_PREFIX = "kdevops"
> +#
> +# [ Workflow: fstests ]
> +#
> +# Running fstests against only a set of tests
> +# TESTS = "generic/531 xfs/008 xfs/013"
> +#
> +# Running fstests from a specific starting point
> +# START_AFTER = "generic/451"
> +#
> +# SOAK_DURATION = ""
> +# FSTESTS_GROUP = ""
> +#
> +# [ Workflow: linux ]
> +#
> +# LINUX_TREE = ""
> +# LINUX_TREE_REF = ""
> +# B4_MESSAGE_ID = ""
> +#
> +# [ Workflows: CI ]
> +#
> +# CI_WORKFLOW = "blktests_block"
> 
> ---
> base-commit: 4d8e5043bf64d51fe391245d1526c1c65617e437
> change-id: 20250704-b4-params-1b98406cbbea
> prerequisite-change-id: 20250430-ansible_cfg_inventory-7955944ce8ff:v4
> prerequisite-patch-id: a6c8585cae96f5a44064b18d68113d6bb9e36584
> prerequisite-patch-id: e27d48a419b82a0fa1af06d78da315c9ef36c8b8
> prerequisite-patch-id: 87405487f3863f93b623f391d46333fb50b9c148
> prerequisite-patch-id: c628eed9f004f0d494a7fc028bc2c1398da511e5
> prerequisite-patch-id: 95108ed1160cfe3bcc87f141e0508efc2c08cf47
> prerequisite-patch-id: 5962dc6100eae5658513ef88c22175988763aa4b
> prerequisite-patch-id: 19a992e90eed8faa04f20d122d4d3d5a51f2ea77
> prerequisite-patch-id: db660adc9266da83e6dad6d4df59ecd7538b32bb
> prerequisite-patch-id: 5f05abf3975b5e8168ac56b8a3ce1c9b2eacf41d
> prerequisite-patch-id: 0eb292f5292f2748fcc794c91ec978c8816c4ffc
> prerequisite-patch-id: ecad3ea874604b00af65ed08c65368db0d95f1c0
> 
> Best regards,
> --  
> Daniel Gomez <da.gomez@samsung.com>
> 


-- 
Chuck Lever

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

[Daniel Gomez]

On 04/07/2025 17.26, Chuck Lever wrote:
> On 7/4/25 7:26 AM, 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 meant to send this as RFC but I forgot to change the prefix before sending.
I'll keep as is for the next iterations.

> 
> Why is a new Kconfig option needed? Instead, can the param.mk file
> either exist or not, and "make" will work either way?

I agree. At first, I had it disabled by default in the new Kconfig option. But
I don't see why not having always this feature (no kconfig needed). If the file
is not present then, it will create one based on the sample file and everything
would be comment it out.

> 
> 
> I'm glad to see the comments documenting each variable in the sample
> file. Some of these I did not know about before. Are they documented
> somewhere else as well? Having them all in one place is great.

I think documentation may be spread. But adding a standalone documentation file
for cli + the sample config is not incompatible. I'll work on that.

> 
> But, the use of "[ section name ]" suggests this file might be an
> INI file, though it's actually just "VAR = value" with comments. A
> block comment at the top that explains the format would be helpful,
> and perhaps find a different way of demarcating the sections.

Thanks for the suggestion and examples. Makes sense to me.

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

[Daniel Gomez]

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?

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

[Luis Chamberlain]

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

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

[Daniel Gomez]

On 23/08/2025 22.54, Luis Chamberlain wrote:
> 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.

My bad. I meant replacing (not dropping) the current CLI with the config script.
We gain access to all configs instead of a subset at the cost of going through
a configuration step.

Note that for the TESTS example, we'd need to expose it as kconfig option as
mentioned in my previous email.

My proposal also suggests using the config script to generate the extra vars
YAML files, which are ultimately what the playbook execution needs for the
current CLI variables.

However, I understand that loosing the runtime path is not desirable. We
are bypassing the config step and that's convenient. I'd say it's general
application behaviour, not kdevops specific.

In a way, the suggestion was to simplify what we discussed here [1].

Link: https://lore.kernel.org/kdevops/c7h4w4jwtrf5q3h77tcxsgpiq7x3ij6zcu5qtmf3akyvntuenb@cesvkshy7xvt/ [1]

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

Regarding Kconfig -> Ansible [1], I have some ideas but I'll postpone and move
it to another thread. Probably, they need "merging" with the SAT solver.

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

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.

Link: https://lore.kernel.org/all/Z-HRF6lZ6dhwFtAS@bombadil.infradead.org/ [2]

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

Agreed, thanks for the discussion. I think it's clear to me now why we want to
keep the CLI.

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.

My proposal for that would be to integrate mergeconfig to provide early SAT
solver support. 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.

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

[Luis Chamberlain]

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