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 9E9D01F4E4F for ; Sat, 23 Aug 2025 20:54:20 +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=1755982460; cv=none; b=Cb3q+WbLA67TQAydWtWZVmmovCkDq+8sOasNdRYZ7UriOIacBGdBFt8x1oFymQ6ENkKKuk/htemYQAjzFmOI6/wWy5dFeyma3JuLg+jC+d8NqepLrhBZDPrGBlvM8iHS2whq5rvEoYcLkz7keQaRCC4mNAemt8/S/9JZ2YNe2HA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755982460; c=relaxed/simple; bh=Ij+3rrGXO4kE7UPfG/XnUV6ux7onAz4biAj4AfBcgJk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SChQUMNcNOEUyYghnzYx2gcnpZZpR2NWyieYff8Cg968IqzoAqAelU+Bu8wT+6VOWj7gsbQZ4Th2yKBvak2iznwq/XcHyu0uSWR7EhiICr4hTkdCCfDWu6LrI3ktGTw96tuynJMvTDrwfhH21CkR1cG13DJF3otNaMKcVdio71Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HUOU1Ns8; 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="HUOU1Ns8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54B28C4CEE7; Sat, 23 Aug 2025 20:54:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755982460; bh=Ij+3rrGXO4kE7UPfG/XnUV6ux7onAz4biAj4AfBcgJk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HUOU1Ns8jMr+wf2r//XT9tNyyUUX4lwfgFkFABqv2WjJmqqH/8dYiNzP5dHLmFN3M m1lPGACeCE1y4hfP2bN9XFnu+uIZGEY7B9H3daD8cIeBpKr7JzC/Z+IZ1lTw0Lutb7 i1MZ/jSNzmT3Ryobd6tZq+zFHs2DblM3bNA+8twjP5nbYxJ3I0FVq0mj2g4f0q7aGu aMfGEaBEd9uKAj8SCojyevVvrR03GTWbNvYIJWGcWrlwTUQYmGtLUrxI6YH15QsZMT F/9isXLL7zwyJ1zZ9L8F/9LGfeLeHtJtHdTj9OYCAuuI7inqIDkWptKqBjefcHcJ7E oLwSms9dqkNaw== Date: Sat, 23 Aug 2025 13:54:18 -0700 From: Luis Chamberlain To: Daniel Gomez Cc: Chuck Lever , kdevops@lists.linux.dev, Daniel Gomez Subject: Re: [PATCH] Makefile: Add support for user makefile params Message-ID: References: <20250704-b4-params-v1-1-42dd4ff478b3@samsung.com> <10d358ca-654f-4a17-ac1f-0c1c56b3662c@kernel.org> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10d358ca-654f-4a17-ac1f-0c1c56b3662c@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 > > > > 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? 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