From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 407341DF74F for ; Thu, 21 Aug 2025 09:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755768916; cv=none; b=JASt2UAglQg5QXzvVjPTVVUquICgzopnezG+VPt4sJlhcbJPeaDICa+BMPT1taHXai/q66tXoQlbH0dGQizetnjpauL5ywDgZ9ruJzA9f2dzPPslL6w0VY2g06sS3WvkKeYRg7bmUvz7weiwf0SBzcjz26HVHJBU9wYOUMizylQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755768916; c=relaxed/simple; bh=uLYIrvpHVjEOvySIAWZVVGYKwElqOsOVbdlB9jWnyqI=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=G4NZ30qgvSHiCZGpHhah7iUOSQ+Jyu3j/CfeihAiIthpBcDDC6SQCNT3wAfYwiGAHRcQdk5hzvo7PWP6Vte4FjbwcSXDBR0h37PHO8YeBhLcQTZAMPgcvaWvpttATYKDmyM6MYehndqj7yVEOc+C+mjIxwgtqTyCqaTwgy2/VpM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=emBJ9ru9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="emBJ9ru9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A81C9C4CEEB; Thu, 21 Aug 2025 09:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755768914; bh=uLYIrvpHVjEOvySIAWZVVGYKwElqOsOVbdlB9jWnyqI=; h=Date:From:Subject:Reply-To:To:Cc:References:In-Reply-To:From; b=emBJ9ru9vv4YHmusNav6HlJXV4RGXL8rQMD1GjY/NQxZtNZNI9NwxTDJOYupC2S/T L8SjbVtAHJbUuHEFzxaWokBINM2M00yYzb1pvM0NAsJTKcpcTCV0DFnCTSy6zYyWOx kXeAHjdR+iLg7ypTYfGp3/PEQe9m04gmETgUNGALfFjSY9ZzzRXdbDuuHoPIh0L5sS 48nV4UIUKS9x2DBIVUZZ1hNKcmb0oIvCkbzGeUBsn6cMM3wzZdrlK2BqoaMYVjs0kI noaOJI9YXelCgWP8Pv5IItQo3sGkjtWcLwcB3N1EOxvGadOk5tnYTLpiDdS9N1BlSp aIJN+kwNitm0w== Message-ID: <10d358ca-654f-4a17-ac1f-0c1c56b3662c@kernel.org> Date: Thu, 21 Aug 2025 11:35:11 +0200 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Daniel Gomez Subject: Re: [PATCH] Makefile: Add support for user makefile params Reply-To: Daniel Gomez To: Luis Chamberlain , Chuck Lever Cc: kdevops@lists.linux.dev, Daniel Gomez References: <20250704-b4-params-v1-1-42dd4ff478b3@samsung.com> Content-Language: en-US Organization: kernel.org In-Reply-To: <20250704-b4-params-v1-1-42dd4ff478b3@samsung.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/07/2025 04.26, Daniel Gomez wrote: > From: Daniel Gomez > > 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 > --- > 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?