On Wed, 2 Sep 2026 14:22:04 +0800, Hangbin Liu wrote:
>Hi Qianheng,
>On Wed, Sep 02, 2026 at 11:05:42AM +0800, Qianheng Peng wrote:
>> >Oh, I see what you mean now.
>> >
>> > kselftest_cmd_args_ref="KSELFTEST_${BASENAME_SANITIZED}_ARGS"
>> >
>> >This is used to retrieve parameters for a *specific* test. When a test does
>> >not
>> >require extra parameters, `KSELFTEST_${BASENAME_SANITIZED}_ARGS` is not set.
>> >This has the same effect as when a user exports it but does not assign a
>> >value.
>> >
>> >Therefore, I do not think we need to add a check for this case. Users should
>> >understand the semantics when exporting the
>> >`KSELFTEST_${BASENAME_SANITIZED}_ARGS`
>> >variable.
>> >
>> >Thanks
>> >Hangbin
>>
>> Yes, if just only adding a check, that really makes no sense.
>> But there is a issue for the follow case:
>> ---------------------------------------------------------------------------
>> User wrote "cmd_args=nice_value" in settings file and want to use the
>> `nice_value` as arguments for a test program.So the user didn't need to
>> export something like `KSELFTEST_XXXX_ARGS` because kselftest_cmd_args should
>> get the `nice_value` as we can see
>>
>> eval "kselftest_$field"="$value"
>
>AFAIK, the setting file is usually used for setting timeout value. As
>you can see in runner.sh, it checks kselftest_timeout after reading setting
>file.
>
Yes, I see it. Basically I did similar things to kselftest_cmd_args like things
that
runner.sh did to kselftest_timeout.
>> But in current runner.sh, kselftest_cmd_args has always been set up by
>> `KSELFTEST_XXXX_ARGS` as we can see
>>
>> kselftest_cmd_args_ref="KSELFTEST_${BASENAME_SANITIZED}_ARGS"
>> eval kselftest_cmd_args="\$${kselftest_cmd_args_ref:-}"
>>
>> As `KSELFTEST_XXXX_ARGS` was empty, the user unexpectedly lost `nice_value`
>> written in settings file.
>> ---------------------------------------------------------------------------
>>
>> According to the implement of runner.sh, it may want to give users two
>> choices:
>> 1) using arguments in settings file
>
>I’m not sure if this was the original intention. The configuration file
>lives under the test directory, which typically holds multiple tests.
>What if individual tests require different parameters? How would you
>supply distinct arguments in the config file using only a single
>`cmd_args` variable?
>
Yeah, settings file can't cover every different parameter(maybe neither
timeout).
So `cmd_args` in settings file is only fit for single test which needs special
parameter such as setting `test_range=1,976` for test_kmod.sh of bpf directory,
however other bpf tests can ignore the parameter.
>> 2) or using arguments by export `KSELFTEST_${BASENAME_SANITIZED}_ARGS`
>> But now users has been forced to use `KSELFTEST_${BASENAME_SANITIZED}_ARGS`.
>
>In contrast, `KSELFTEST_${BASENAME_SANITIZED}_ARGS` can target each specific
>test case individually.
>
>Perhaps I have misunderstood the design. Please feel free to correct me.
>
I think you are right. I am also not sure the original intention as I just found
current runner.sh had the feature which can retrieve cmd_args from settings
file.
This feature made me think it can be convenient for users who didn't want to
export `KSELFTEST_${BASENAME_SANITIZED}_ARGS` everytime they start one test.
Anyway, glad to recieve more advice whatever next step has more work to do or
nothing to do.
Thanks and regards,
Qianheng
>Thanks
>Hangbin
>>
>> For the case above and making users happy, I did two things in the patch:
>> 1) If `KSELFTEST_${BASENAME_SANITIZED}_ARGS was empty, keep the value from
>> settings file
>> 2) If not, set kselftest_cmd_args by `KSELFTEST_${BASENAME_SANITIZED}_ARGS`
>>
>> Thanks and regards,
>> Qianheng
