Re: [PATCH] kconfig: add optional warnings for changed input values

[Nicolas Schier]

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.
> 
> 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.
> 
> 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.
> 
> Document the new environment variable and add tests for both olddefconfig
> and savedefconfig.
> 
> Signed-off-by: Pengpeng Hou <pengpeng@xxxxxxxxxxx>
> ---

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 = str_new();
>  	FILE *out;
> +	bool warn_changed_input = conf_warn_changed_input_enabled();
> +	bool found = 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 = str_new();
>  	bool need_newline = false;
> +	bool warn_changed_input = conf_warn_changed_input_enabled();
> +	bool found = false;
>  
>  	if (!name)
>  		name = 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 menu
| traversal encounters the same symbol at its next menu node, it will process 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 <nsc@xxxxxxxxxx>
Reviewed-by: Nicolas Schier <nsc@xxxxxxxxxx>

Thanks!


[1]: http://sashiko.dev/#/patchset/20260406233001.1-kconfig-warn-changed-input-pengpeng%40iscas.ac.cn

Attachment: signature.asc
Description: PGP signature