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 6DEE9273D65 for ; Wed, 27 Aug 2025 20:34:59 +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=1756326899; cv=none; b=ciuENfkZuhOypCVA/Qi9HXhgPK7z72jG7sM6nPUruUkeMM/JO49oC6RWp9pMtfYgQueinY2MKb73vrQmM7zOM0Yiz7cQVvAAyf0wAthANYnkgXTFAdZ2FLwedoHRXhhNs78P6Fakr7rCHDoJRYrTEbFslmvicln9RfKeM9x9Uys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756326899; c=relaxed/simple; bh=UYmGSMmZetbq3SFssLuRXdd1tsDlpVaa+Y7jG+0egXY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NCbdaGwPsb3j6/nhSirF9rShZr1q4bsA6EQb4Mgto5v9gbuLMuohVnrP2H9bAauIvvA58BYgt6WCEidxjIls6183i1LfQd5IuFkEh3ktZLj+TlYzJEgbe48eh/jd6+jZAo61paEbOkzOPw/3nL4+GprHHLFgz8L69aKzZ8qu9Ho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NL2EwGDk; 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="NL2EwGDk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDD7FC4CEF4; Wed, 27 Aug 2025 20:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756326899; bh=UYmGSMmZetbq3SFssLuRXdd1tsDlpVaa+Y7jG+0egXY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NL2EwGDkOMFPnhAc2MTszULGBe8qE29OJU7FZomNyQOHxvT51K23kgauAkr8OO6MO kmf6y+tuAn/UzW5VX8sAmxLIJyzcXhS3js5w/8MqnlFRYWFzNimcSIpqhw4zf/pIt2 jN6PawJBMeOT4lrPb1jw9xtuUploe3nBinnMHO6etmGI7IeTofpmype8U1SPxeA/O6 SeAW74WJeZ9J9XQsLG0VjlEQQRHZHm6BPONapg6qT6MHGah8wm/SdZCupFYJM2mG3F NUvu1wzp9Wslo+rmDcuEEINL5sr5JpQoFmJtWHQzBcU4urvkwB8VAyDwqgwyYD2q0E Tqa5nGYGHw3FA== Date: Wed, 27 Aug 2025 13:34:57 -0700 From: Luis Chamberlain To: Daniel Gomez Cc: Chuck Lever , kdevops@lists.linux.dev, Daniel Gomez , Ole Schuerks 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> <0f6ce4f1-6abc-455f-9c94-a982091052d4@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: <0f6ce4f1-6abc-455f-9c94-a982091052d4@kernel.org> 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