Re: [PATCH v2] merge_config.sh: do not report some differencess between input and output

From: Lukasz Stelmach
Date: Thu Feb 23 2023 - 18:30:26 EST


It was <2023-02-16 czw 21:17>, when Masahiro Yamada wrote:
> On Wed, Feb 8, 2023 at 10:08 PM Łukasz Stelmach <l.stelmach@xxxxxxxxxxx> wrote:
>>
>> If an input config file contains CONFIG_FOO=n the output one
>> will contain a line '# CONFIG_FOO is not set'. merge_config.sh
>> should not report it as difference because the end result of
>> CONFIG_FOO being disabled is achieved.
>>
>> Inexistence of CONFIG_FOO (because of unment dependencies) in case
>> CONFIG_FOO=n is requested, should also be ignored.
>>
>> Change-Id: I129f3a0b4205a76d8c42020f8adb72b1889d75fb
>> Signed-off-by: Łukasz Stelmach <l.stelmach@xxxxxxxxxxx>
>> ---
>> Changes in v2:
>> - suppress reports reports if an option was "not set" in input files
>> but is missing from the filnal .config due to unmet dependecies.
>> - apply the same logic to suppress some reports during the merging
>> phase
>>
>> BTW. Do you think adding "| sort -u" after "grep -w" to avoid reports
>> about repeated entries may make sense or do you want such reports to
>> be printed.
>>
>> scripts/kconfig/merge_config.sh | 30 ++++++++++++++++++++----------
>> 1 file changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
>> index e5b46980c22a..1086bdc7abf2 100755
>> --- a/scripts/kconfig/merge_config.sh
>> +++ b/scripts/kconfig/merge_config.sh
>> @@ -144,12 +144,17 @@ for ORIG_MERGE_FILE in $MERGE_LIST ; do
>> echo
>> BUILTIN_FLAG=true
>> elif [ "x$PREV_VAL" != "x$NEW_VAL" ] ; then
>> - echo Value of $CFG is redefined by fragment $ORIG_MERGE_FILE:
>> - echo Previous value: $PREV_VAL
>> - echo New value: $NEW_VAL
>> - echo
>> - if [ "$STRICT" = "true" ]; then
>> - STRICT_MODE_VIOLATED=true
>> + if [ \( "x$PREV_VAL" != "x$CFG=n" -a \
>> + "x$PREV_VAL" != "x# $CFG is not set" \) -o \
>> + \( "x$NEW_VAL" != "x" -a \
>
>
>
> In which case does $NEW_VAL become empty?

You are right, there is now such case.

> I think it is opposite.
> $PREV_VAL might be empty, $NEW_VAL may specified as =n.

Let me try to determine when we would like to see complaints about
changes being made to config options


| PV\NV | y | m | n | n-s |
|-------+---+---+---+-----|
| y | o | x | x | x |
| m | x | o | x | x |
| n | x | x | o | / |
| n-s | x | x | / | o |
| empty | o | o | o | o |

o - OK, don't rport
x - switched, report
/ - "n" and "not-set" are synonyms, don't report

This gives us the following conditions three conditions under which to report value changes.

(PREV_VAL != "") &&
(NEW_VAL != PREV_VAL) &&
((PREV_VAL != "n" && PREV_VAL != "not-set") ||
(NEW_VAL != "n" && NEw_VA L != "not-set"))

Does it make sense?

>
>
>
>
>> + "x$NEW_VAL" != "x# $CFG is not set" \) ]; then
>> + echo Value of $CFG is redefined by fragment $ORIG_MERGE_FILE:
>> + echo Previous value: $PREV_VAL
>> + echo New value: $NEW_VAL
>> + echo
>> + if [ "$STRICT" = "true" ]; then
>> + STRICT_MODE_VIOLATED=true
>> + fi
>> fi
>> elif [ "$WARNREDUN" = "true" ]; then
>> echo Value of $CFG is redundant by fragment $ORIG_MERGE_FILE:
>> @@ -196,9 +201,14 @@ for CFG in $(sed -n -e "$SED_CONFIG_EXP1" -e "$SED_CONFIG_EXP2" $TMP_FILE); do
>> REQUESTED_VAL=$(grep -w -e "$CFG" $TMP_FILE)
>> ACTUAL_VAL=$(grep -w -e "$CFG" "$KCONFIG_CONFIG" || true)
>> if [ "x$REQUESTED_VAL" != "x$ACTUAL_VAL" ] ; then
>> - echo "Value requested for $CFG not in final .config"
>> - echo "Requested value: $REQUESTED_VAL"
>> - echo "Actual value: $ACTUAL_VAL"
>> - echo ""
>> + if [ \( "x$REQUESTED_VAL" != "x$CFG=n" -a \
>> + "x$REQUESTED_VAL" != "x# $CFG is not set" \) -o \
>> + \( "x$ACTUAL_VAL" != "x" -a \
>> + "x$ACTUAL_VAL" != "x# $CFG is not set" \) ]; then
>> + echo "Value requested for $CFG not in final .config"
>> + echo "Requested value: $REQUESTED_VAL"
>> + echo "Actual value: $ACTUAL_VAL"
>> + echo ""
>> + fi
>> fi
>> done
>> --
>> 2.30.2
>>

--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

Attachment: signature.asc
Description: PGP signature