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

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

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.