From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 1B1642BE7AB; Wed, 20 May 2026 14:32:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779287542; cv=none; b=JBpUsykj7h8NH/iuxKBf+OiViMEHV6DiJrubkM1Rhe4QJNirQTMqh4vbdr1588lYaK4peHntfpFfLvpoVasOHkTU1n7b5GwH7rG4CC9ORYsLBpADBbysGwYXuhsb7pU/m+tyIHLh1Lc4fTs0wV9LS/uLZHnfdVPqVw2L/g7r8uo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779287542; c=relaxed/simple; bh=jLham3+OIjKRsTPNXvnvLvMW6DyEontRwkPGpdUjMf0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q+T3YYVYtW7J7XHEvOl2+iGsqccoxIL3CIvt/aOPJGFA9Uwq8bUaWFK3nGo/ksXt7N6TDFzUfMnQx7HmuouQybSxDf8bO88k7MDDKtJgH0EuhkVPUEr8jUZb2nCZUbu1SjUzfK7NDufQk9FB+P3+PKC58KI/xl485qr+/D5xJo4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iJB/TuTo; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iJB/TuTo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10BE61F000E9; Wed, 20 May 2026 14:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779287540; bh=vAqhXt6lj82URSARgDuUgxS2ppBm7kavWdsFVsDgvR8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iJB/TuTo8LqLljfJT2TklC0tI/G/ecO3RlukG11d8nNF5K+xBqId6olm7ulsg4wQ9 CLKyPye02eFfossrMdhOBI6ogKZXxneKqy8SHfUgr5ZMlkifbhb0zmzRtASQ9B3egS 9oGoil0kY5cxxeiepDF8lF0PuTeqRevBDa9IL9l1es+yizXK5p+haaorsCMP/RBZnX WBrJd6bqTYWqORtdq+v5iOvJRWSYHWffZWQaaVmlha5YHqG+NK6bTaBWad8OcREAGB 0llrT/fiGMcVtvynmcN7Dj2IxI4XFqpbY6A90qKKXu7Tk47Bl186M8un6/YMVBvNBI hE1t4e5WORTlg== Date: Wed, 20 May 2026 16:31:30 +0200 From: Nicolas Schier To: Pengpeng Hou Cc: Nathan Chancellor , Masahiro Yamada , linux-kbuild@vger.kernel.org, Jonathan Corbet , Shuah Khan , Randy Dunlap , Thomas Meyer , Miguel Ojeda , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kconfig: add optional warnings for changed input values Message-ID: References: <20260406233001.1-kconfig-warn-changed-input-pengpeng@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wm9TWPGmtFDoyYd+" Content-Disposition: inline In-Reply-To: <20260406233001.1-kconfig-warn-changed-input-pengpeng@iscas.ac.cn> --wm9TWPGmtFDoyYd+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 06, 2026 at 11:06:19PM +0800, Pengpeng Hou wrote: > When reading .config input, Kconfig stores user-provided values first and > then resolves the final value after applying dependencies, ranges, and > other constraints. >=20 > If the final value differs from the user's input, Kconfig already tracks > that state internally, but it does not provide any focused diagnostic to > show which explicit inputs were adjusted. This is particularly confusing > for requested values that get forced down by unmet dependencies or clamped > by ranges. >=20 > Add an opt-in diagnostic controlled by KCONFIG_WARN_CHANGED_INPUT. > Emit the warnings from conf_write() and conf_write_defconfig() after > value resolution and through the existing message callback path so the > default behavior stays unchanged and interactive frontends remain usable. >=20 > Document the new environment variable and add tests for both olddefconfig > and savedefconfig. >=20 > Signed-off-by: Pengpeng Hou > --- Thanks a lot for this patch! I know quite some people waiting for that feature! Just a minor nit-pick, and two minor issues found from Sashiko; see below. [...] > @@ -759,7 +825,10 @@ int conf_write_defconfig(const char *filename) > { > struct symbol *sym; > struct menu *menu; > + struct gstr gs =3D str_new(); > FILE *out; > + bool warn_changed_input =3D conf_warn_changed_input_enabled(); > + bool found =3D false; nit-picking: I'd favor a more descriptive variable name (e.g. 'changed_input_found'), as I am expecting my future me to have to dig into conf_warn_changed_input_enabled() what that 'found' might really mean. [...] > @@ -798,6 +870,13 @@ int conf_write_defconfig(const char *filename) > print_symbol_for_dotconfig(out, sym); > } > fclose(out); > + > + conf_clear_written_flags(); > + > + if (found) > + conf_message("%s", str_get(&gs)); Sashiko complains [1] that conf_message() may truncate the output to 4096 bytes, which can easily be provoked, e.g. by switching ARCH. [...] > @@ -809,7 +888,10 @@ int conf_write(const char *name) > const char *str; > char tmpname[PATH_MAX + 1], oldname[PATH_MAX + 1]; > char *env; > + struct gstr gs =3D str_new(); > bool need_newline =3D false; > + bool warn_changed_input =3D conf_warn_changed_input_enabled(); > + bool found =3D false; > =20 > if (!name) > name =3D conf_get_configname(); > @@ -859,6 +941,8 @@ int conf_write(const char *name) > } else if (!sym_is_choice(sym) && > !(sym->flags & SYMBOL_WRITTEN)) { > sym_calc_value(sym); > + if (warn_changed_input) > + conf_append_changed_input_warning(&gs, sym, &found); > if (!(sym->flags & SYMBOL_WRITE)) > goto next; Sashiko asks about possibly duplicated warnings: | Will duplicate warning messages be emitted for symbols that have multiple= menu | entries and are forced off (so SYMBOL_WRITE is not set)? | Since this skips the rest of the loop via goto next;, the symbol is never | marked with SYMBOL_WRITTEN (which happens later in the block). When the m= enu | traversal encounters the same symbol at its next menu node, it will proce= ss it | again and redundantly append the exact same warning. But from what I can find in in-tree Kconfigs, we do not have Kconfig symbols that are accessible from multiple menu entries. But it would be good if someone else could check that once again. So, thanks again for this small but great feature! Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Thanks! [1]: http://sashiko.dev/#/patchset/20260406233001.1-kconfig-warn-changed-in= put-pengpeng%40iscas.ac.cn --wm9TWPGmtFDoyYd+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEh0E3p4c3JKeBvsLGB1IKcBYmEmkFAmoNxboACgkQB1IKcBYm EmnW0A//X1DFcP9L3Yi6vWlAVgwgeuv6tUS3P/LzIOzh0q03K6nUmaOUtjfi5/rN ZKCfekxNGopRcyofRo1cLi1KfwWxkR1zhNCNJkwcIMbME6OfnnKscVN53nQUPIR5 ilUhjxu4ndaKK/6i3fYMEG7YmjLokL1aSHgakNEX40s4WgKc0QI+laWorhitK92R 1FLr8zlKyRxXTyyrraOEaSKjCf4Wp3AuN7t0Dgb6pU2oEtnuakG7W8soUoXvy+mU mt3VSIIulQDXozuFDSW+omzQJqVI0wDlOclJpbwAR81eRYcbRpOKudJEa5XwvM2h f3bpwICkNmvTr2FlSRbsyx3f7Q84KLqa1kF253Sv5Ao5YIEOFbgNu4M7LBw91dlN KKSTvVpLY+mlQ5Nro5qJyfjP0vLkKqGTLrmXJgai/HY/lrJ5ZPk9HIk0z+fKd4hz WEB5tukWS21UQyAaBVvqYkSs4b38Hbs5sKMWO3W+sbzGCt/Y6t2IZOaMqlV9x2Ct GHqDPoXnq52uPJJU4HQ2SlcRW4NcrTjUBU4LH67C/ipk/86YXg4wbryZMmeiZwhx 15UxYEuIEgTPPTo6FFhyiho8hN6iwubBOk/MVbP9M+LcEU2ETSk3hUzQet3VUayy FM/jKhLLiIXaKb/ARZW9LFSCQO8QVtdes/J/jChYUbepLAzgjU8= =OvwS -----END PGP SIGNATURE----- --wm9TWPGmtFDoyYd+--