From: Jordan Richards <jordanrichards@google.com>
To: rppt@kernel.org
Cc: dmatlack@google.com, jasonmiu@google.com,
jordanrichards@google.com, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
shuah@kernel.org
Subject: Re: [PATCH] selftests/liveupdate: add end to end test infrastructure and scripts
Date: Thu, 5 Feb 2026 22:11:22 +0000 [thread overview]
Message-ID: <20260205221122.2415333-1-jordanrichards@google.com> (raw)
In-Reply-To: <aXj28ZAsPhp7s5sm@kernel.org>
Sending v2 addressing this feedback soon:
>> + err = kexec_file_load(kernel_fd, initrd_fd, strlen(cmdline) + 1,
>> + cmdline, 0);
>> +
>> + close(initrd_fd);
>> + close(kernel_fd);
>> +
>> + return err ? : 0;
>
> Just return err?
Good point, fixed.
>> diff --git a/tools/testing/selftests/liveupdate/luo_test.sh b/tools/testing/selftests/liveupdate/luo_test.sh
>> new file mode 100755
>> index 000000000000..90ecb16e87bb
>> --- /dev/null
>> +++ b/tools/testing/selftests/liveupdate/luo_test.sh
>
>...
>
>> +function detect_cross_compile() {
>> + local target=$1
>> + local host=$(uname -m)
>> +
>
> This function works fine if you run luo_test.sh directly or have cross
> compilers named the way it expects in $PATH.
>
> But if I run
> CROSS_COMPILE=~/cross/gcc-13.2.0-nolibc/aarch64-linux/bin/aarch64-linux- ./run.sh
> on x86, x86 tests fail
>
>> + if [ -n "$CROSS_COMPILE" ]; then
>> + return
>> + fi
>> +
>> + [[ "$host" == "arm64" ]] && host="aarch64"
>> + [[ "$target" == "arm64" ]] && target="aarch64"
>> +
>> + if [[ "$host" == "$target" ]]; then
>> + CROSS_COMPILE=""
>> + return
>> + fi
The host==target test needed to be first, fixed.
>> + local fragments=()
>> +
>> + if [[ -f "$common_conf" ]]; then
>> + fragments+=("$common_conf")
>> + fi
>> +
>> + if [[ -f "$arch_conf" ]]; then
>> + fragments+=("$arch_conf")
>> + fi
>
> I think the common and arch config fragments are required and we can just
> assign fragments directly and run merge_config.sh.
Done.
I wasn't sure if arch_conf would be necessary for all architectures, but it
is kind of needless complexity.
> + if [[ "$qemu_cmd" == *"$host_machine"* ]]; then
> + if [ -w /dev/kvm ]; then
> + accel="-accel kvm"
> + fi
> + fi
>
> Do we care that much about qemu warnings about invalid accelerator to have
> this logic here?
>
> -accel kvm -accel hvf -accel tcg
>
> seems to cover all bases.
The warning doesn't break the tests, so it should be fine.
>> +#include <sys.h>
>
> This breaks running normal make:
>
> luo_test_utils.c:16:10: fatal error: sys.h: No such file or directory
> 16 | #include <sys.h>
> | ^~~~~~~
>
> NOLIBC specific includes and calls should be guarded with #ifdef NOLIBC
Done.
> diff --git a/tools/testing/selftests/liveupdate/run.sh b/tools/testing/selftests/liveupdate/run.sh
> new file mode 100755
> index 000000000000..3f6b29a26648
> --- /dev/null
> +++ b/tools/testing/selftests/liveupdate/run.sh
> @@ -0,0 +1,68 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +
>> +OUTPUT_DIR="results_$(date +%Y%m%d_%H%M%S)"
>
> I don't think that putting the results in the current directory rather than
> in SCRIPT_DIR or in an explicitly named directory is a good idea.
Changed to "$SCRIPT_DIR/results_*".
>> +TEST_NAMES=()
>> +while IFS= read -r file; do
>> + TEST_NAMES+=("$(basename "$file" .c)")
>> +done < <(find "$SCRIPT_DIR" -maxdepth 1 -name "luo_*.c" ! -name "luo_test_utils.c")
>
> I don't like name based detection of tests. Listing them explicitly seems a
viable option.
Agreed, changed to a fixed array.
prev parent reply other threads:[~2026-02-05 22:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 21:44 Jordan Richards
2026-01-27 17:33 ` Mike Rapoport
2026-01-29 22:51 ` David Matlack
2026-02-02 21:48 ` Jordan Richards
2026-02-03 18:24 ` Mike Rapoport
2026-02-05 22:11 ` Jordan Richards [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260205221122.2415333-1-jordanrichards@google.com \
--to=jordanrichards@google.com \
--cc=dmatlack@google.com \
--cc=jasonmiu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox