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 B4F6729ACC5 for ; Mon, 25 Aug 2025 08:01:22 +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=1756108882; cv=none; b=RRFJBdJ79IsGm5oMsNFUXZad0c5bBHWPlL4TLUBqBcBN+1w2zqZ1MeuHnY8lz4sS7+RzT+MlYtwsR62hO6s5vvfRc7Wf8WWUmM2iwazTMRNTmVBAOu5ybmPZ9ZYt53F5ZIyZhkrvsQN5CefZkMux3S0n7owmiT5ePMdZCy2gbQw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756108882; c=relaxed/simple; bh=hc47sdr+jEMlK+ci6EzW9ZtrYY4OFDvZ01ar7CT3X14=; h=Message-ID:Date:MIME-Version:Subject:To:References:From:Cc: In-Reply-To:Content-Type; b=Lf6r35ASHyCBmU97VVE7Sf+upIo9/VMXOESyVevWGVNR3UxXjNNCywlOQMtZriv/wlHFiFRoZOUzpIjR0k2HXHlYwMH1PqHikhXxpz9ZZQJ08nHW8T6H/z8dp7u0e3VE0v2fqCqzudS2YGITl/b09jtc+jBX0k+THlMhcpXwftg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e47j4EnM; 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="e47j4EnM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 390FBC116B1; Mon, 25 Aug 2025 08:01:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756108882; bh=hc47sdr+jEMlK+ci6EzW9ZtrYY4OFDvZ01ar7CT3X14=; h=Date:Reply-To:Subject:To:References:From:Cc:In-Reply-To:From; b=e47j4EnMq6p+gE6wyxO32GpbNHbMfak1yywDulrrLgYfPXr9YXtB7SAN/POdFmaut rbwgEDEXlk3cAMOhjQKtgfLVWSjmUh83ZMdwU1e4ZwSaBRUR+H90fiRRjq7o//VykN 7tthroR55w/JbUqN17HiwaR0jUJaTEeEW3SJGJinLRlSn0FiW1jGoayDUppmasz6+I QPBveoR9JuiwhIFGa7mF17nAsn1OOMnbL+xxuyCdVkoZw6QblnAMiC9zJ+2b/ykAwn 07vxE7vr6L35vbWlOb4cxmOF/psKPus4Hf1qvhgP0+U0ITL/BtKdADfyhvXMlWRFEu BV4Zpp4oYvMeg== Message-ID: <0f6ce4f1-6abc-455f-9c94-a982091052d4@kernel.org> Date: Mon, 25 Aug 2025 10:01:19 +0200 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Daniel Gomez Subject: Re: [PATCH] Makefile: Add support for user makefile params To: Luis Chamberlain References: <20250704-b4-params-v1-1-42dd4ff478b3@samsung.com> <10d358ca-654f-4a17-ac1f-0c1c56b3662c@kernel.org> Content-Language: en-US From: Daniel Gomez Organization: kernel.org Cc: Chuck Lever , kdevops@lists.linux.dev, Daniel Gomez In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 >>> >>> 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. 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.