[LTP] [PATCH 0/6] [RFC,WIP] shell loader fixes + du01.sh rewrite

[LTP] [PATCH 0/6] [RFC,WIP] shell loader fixes + du01.sh rewrite

[Petr Vorel]

Hi,

TODO / to be decided:
Should be setup run only once like in C API and tst_test.sh? If yes, it
should probably be run only on first iteration => see commit
"[WIP,RFC] tst_run.sh: Run setup() only once"


Petr Vorel (6):
  tst_run.sh: Fix passing arguments
  tst_env.sh: Backport common functions from tst_test.sh
  shell_loader: Start test count from 1
  run_shell_tcnt: Add test count also for test_all
  [WIP,RFC] tst_run.sh: Run setup() only once
  du01.sh: Rewrite into shell loader

 testcases/commands/du/du01.sh | 88 +++++++++++++++++++++--------------
 testcases/lib/tst_env.sh      | 71 ++++++++++++++++++++++++++++
 testcases/lib/tst_run.sh      |  6 +--
 testcases/lib/tst_run_shell.c | 12 ++---
 4 files changed, 134 insertions(+), 43 deletions(-)

-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH 1/6] tst_run.sh: Fix passing arguments

[Petr Vorel]

tst_run_script() in C API correctly sets environment, but it have to be
also passed to the shell functions.

Before:

$ ./shell_loader_tcnt.sh
...
shell_loader_tcnt.sh:-1: TPASS: Iteration
shell_loader_tcnt.sh:-1: TPASS: Iteration

After:
shell_loader_tcnt.sh:-1: TPASS: Iteration 0
shell_loader_tcnt.sh:-1: TPASS: Iteration 1

Fixes: 8202494493 ("shell lib: Add basic support for test setup")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
NOTE: not only for TST_CNT like variable, but also for other future
getopts support (needed by tst_net.sh tests).

 testcases/lib/tst_run.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/testcases/lib/tst_run.sh b/testcases/lib/tst_run.sh
index 841b5fd141..e876fd8946 100644
--- a/testcases/lib/tst_run.sh
+++ b/testcases/lib/tst_run.sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0-or-later
 # Copyright (c) 2025 Cyril Hrubis <chrubis@suse.cz>
-# Copyright (c) 2025 Petr Vorel <pvorel@suse.cz>
+# Copyright (c) 2025-2026 Petr Vorel <pvorel@suse.cz>
 
 . tst_env.sh
 
@@ -21,4 +21,4 @@ if [ -n "$TST_SETUP" ]; then
 	fi
 fi
 
-tst_test
+tst_test "$@"
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/6] tst_run.sh: Fix passing arguments

[Li Wang via ltp]

On Fri, Mar 13, 2026 at 03:25:55PM +0100, Petr Vorel wrote:
> tst_run_script() in C API correctly sets environment, but it have to be
> also passed to the shell functions.
> 
> Before:
> 
> $ ./shell_loader_tcnt.sh
> ...
> shell_loader_tcnt.sh:-1: TPASS: Iteration
> shell_loader_tcnt.sh:-1: TPASS: Iteration
> 
> After:
> shell_loader_tcnt.sh:-1: TPASS: Iteration 0
> shell_loader_tcnt.sh:-1: TPASS: Iteration 1
> 
> Fixes: 8202494493 ("shell lib: Add basic support for test setup")
> Signed-off-by: Petr Vorel <pvorel@suse.cz>

Reviewed-by: Li Wang <liwang@redhat.com>

-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/6] tst_run.sh: Fix passing arguments

[Cyril Hrubis]

Hi!
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/6] tst_run.sh: Fix passing arguments

[Petr Vorel]

Hi all,

FYI this patch merged.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh

[Petr Vorel]

Backport common functions from tst_test.sh to the shell loader:

* ROD()
* ROD_SILENT()
* EXPECT_PASS()
* EXPECT_PASS_BRK()
* EXPECT_FAIL()
* EXPECT_FAIL_BRK()
+ their dependencies.

ROD_SILENT will be used in du01.sh rewrite, others will be used likely
in other tests later.

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
 testcases/lib/tst_env.sh | 71 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/testcases/lib/tst_env.sh b/testcases/lib/tst_env.sh
index 585790a7d0..13d8a8f954 100644
--- a/testcases/lib/tst_env.sh
+++ b/testcases/lib/tst_env.sh
@@ -1,6 +1,7 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0-or-later
 # Copyright (c) 2024-2025 Cyril Hrubis <chrubis@suse.cz>
+# Copyright (c) Linux Test Project, 2026
 #
 # This is a minimal test environment for a shell scripts executed from C by
 # tst_run_shell() function. Shell tests must use the tst_loader.sh instead!
@@ -30,3 +31,73 @@ tst_brk_()
 
 alias tst_res="tst_res_ $tst_script_name \$LINENO"
 alias tst_brk="tst_brk_ $tst_script_name \$LINENO"
+
+ROD_SILENT()
+{
+	local tst_out
+
+	tst_out=$(tst_rod "$@" 2>&1)
+	if [ $? -ne 0 ]; then
+		echo "$tst_out"
+		tst_brk TBROK "$@ failed"
+	fi
+}
+
+ROD()
+{
+	tst_rod "$@"
+	if [ $? -ne 0 ]; then
+		tst_brk TBROK "$@ failed"
+	fi
+}
+
+_tst_expect_pass()
+{
+	local fnc="$1"
+	shift
+
+	tst_rod "$@"
+	if [ $? -eq 0 ]; then
+		tst_res TPASS "$@ passed as expected"
+		return 0
+	else
+		$fnc TFAIL "$@ failed unexpectedly"
+		return 1
+	fi
+}
+
+_tst_expect_fail()
+{
+	local fnc="$1"
+	shift
+
+	# redirect stderr since we expect the command to fail
+	tst_rod "$@" 2> /dev/null
+	if [ $? -ne 0 ]; then
+		tst_res TPASS "$@ failed as expected"
+		return 0
+	else
+		$fnc TFAIL "$@ passed unexpectedly"
+		return 1
+	fi
+}
+
+EXPECT_PASS()
+{
+	_tst_expect_pass tst_res "$@"
+}
+
+EXPECT_PASS_BRK()
+{
+	_tst_expect_pass tst_brk "$@"
+}
+
+EXPECT_FAIL()
+{
+	_tst_expect_fail tst_res "$@"
+}
+
+EXPECT_FAIL_BRK()
+{
+	_tst_expect_fail tst_brk "$@"
+}
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh

[Li Wang via ltp]

On Fri, Mar 13, 2026 at 03:25:56PM +0100, Petr Vorel wrote:
> Backport common functions from tst_test.sh to the shell loader:
> 
> * ROD()
> * ROD_SILENT()
> * EXPECT_PASS()
> * EXPECT_PASS_BRK()
> * EXPECT_FAIL()
> * EXPECT_FAIL_BRK()
> + their dependencies.
> 
> ROD_SILENT will be used in du01.sh rewrite, others will be used likely
> in other tests later.
> 
> Signed-off-by: Petr Vorel <pvorel@suse.cz>

Reviewed-by: Li Wang <liwang@redhat.com>


-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh

[Cyril Hrubis]

Hi!
> * ROD()
> * ROD_SILENT()
> * EXPECT_PASS()
> * EXPECT_PASS_BRK()
> * EXPECT_FAIL()
> * EXPECT_FAIL_BRK()
> + their dependencies.
> 
> ROD_SILENT will be used in du01.sh rewrite, others will be used likely
> in other tests later.
> 
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
>  testcases/lib/tst_env.sh | 71 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/testcases/lib/tst_env.sh b/testcases/lib/tst_env.sh
> index 585790a7d0..13d8a8f954 100644
> --- a/testcases/lib/tst_env.sh
> +++ b/testcases/lib/tst_env.sh
> @@ -1,6 +1,7 @@
>  #!/bin/sh
>  # SPDX-License-Identifier: GPL-2.0-or-later
>  # Copyright (c) 2024-2025 Cyril Hrubis <chrubis@suse.cz>
> +# Copyright (c) Linux Test Project, 2026
>  #
>  # This is a minimal test environment for a shell scripts executed from C by
>  # tst_run_shell() function. Shell tests must use the tst_loader.sh instead!
> @@ -30,3 +31,73 @@ tst_brk_()
>  
>  alias tst_res="tst_res_ $tst_script_name \$LINENO"
>  alias tst_brk="tst_brk_ $tst_script_name \$LINENO"
> +
> +ROD_SILENT()
> +{
> +	local tst_out
> +
> +	tst_out=$(tst_rod "$@" 2>&1)
> +	if [ $? -ne 0 ]; then
> +		echo "$tst_out"
> +		tst_brk TBROK "$@ failed"
> +	fi
> +}
> +
> +ROD()
> +{
> +	tst_rod "$@"
> +	if [ $? -ne 0 ]; then
> +		tst_brk TBROK "$@ failed"
> +	fi
> +}

Since we are starting from a scratch I wonder if we should call this
SAFE instead so that the name is closer to the SAFE_XXX macros in C.

> +_tst_expect_pass()
> +{
> +	local fnc="$1"
> +	shift
> +
> +	tst_rod "$@"

If I remmeber correctly the whole reason why we introduced tst_rod.c was
that passing the $@ like this causes the $@ to be evaluated twice and
produces unexpected results.

> +	if [ $? -eq 0 ]; then
> +		tst_res TPASS "$@ passed as expected"
> +		return 0
> +	else
> +		$fnc TFAIL "$@ failed unexpectedly"
> +		return 1
> +	fi
> +}
> +
> +_tst_expect_fail()
> +{
> +	local fnc="$1"
> +	shift
> +
> +	# redirect stderr since we expect the command to fail
> +	tst_rod "$@" 2> /dev/null
> +	if [ $? -ne 0 ]; then
> +		tst_res TPASS "$@ failed as expected"
> +		return 0
> +	else
> +		$fnc TFAIL "$@ passed unexpectedly"
> +		return 1
> +	fi
> +}
> +
> +EXPECT_PASS()
> +{
> +	_tst_expect_pass tst_res "$@"
> +}
> +
> +EXPECT_PASS_BRK()
> +{
> +	_tst_expect_pass tst_brk "$@"
> +}

I'm not sure that adding the PASS_BRK and FAIL_BRK is a good idea. I
would stick to simple EXPECT_PASS and EXPECT_FAIL. And maybe we can
export TST_PASS variable as we do in C to match the API. I think that
the closer the C and shell API are the better.

> +EXPECT_FAIL()
> +{
> +	_tst_expect_fail tst_res "$@"
> +}
> +
> +EXPECT_FAIL_BRK()
> +{
> +	_tst_expect_fail tst_brk "$@"
> +}
> -- 
> 2.51.0
> 

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh

[Petr Vorel]

> Hi!
...

> > +ROD_SILENT()
> > +{
> > +	local tst_out
> > +
> > +	tst_out=$(tst_rod "$@" 2>&1)
> > +	if [ $? -ne 0 ]; then
> > +		echo "$tst_out"
> > +		tst_brk TBROK "$@ failed"
> > +	fi
> > +}
> > +
> > +ROD()
> > +{
> > +	tst_rod "$@"
> > +	if [ $? -ne 0 ]; then
> > +		tst_brk TBROK "$@ failed"
> > +	fi
> > +}

> Since we are starting from a scratch I wonder if we should call this
> SAFE instead so that the name is closer to the SAFE_XXX macros in C.

Makes sense. I was even thinking on SAFE_CMD, but we use tst_rod.c, not
tst_cmd.c. OTOH it was obvious that ROD uses tst_rod.c, should it be also
renamed? What ROD means anyway? run or dye?

> > +_tst_expect_pass()
> > +{
> > +	local fnc="$1"
> > +	shift
> > +
> > +	tst_rod "$@"

> If I remmeber correctly the whole reason why we introduced tst_rod.c was
> that passing the $@ like this causes the $@ to be evaluated twice and
> produces unexpected results.

FYI code is copy pasted from tst_test.sh. What do you want me to change?

> > +	if [ $? -eq 0 ]; then
> > +		tst_res TPASS "$@ passed as expected"
> > +		return 0
> > +	else
> > +		$fnc TFAIL "$@ failed unexpectedly"
> > +		return 1
> > +	fi
> > +}
> > +
> > +_tst_expect_fail()
> > +{
> > +	local fnc="$1"
> > +	shift
> > +
> > +	# redirect stderr since we expect the command to fail
> > +	tst_rod "$@" 2> /dev/null
> > +	if [ $? -ne 0 ]; then
> > +		tst_res TPASS "$@ failed as expected"
> > +		return 0
> > +	else
> > +		$fnc TFAIL "$@ passed unexpectedly"
> > +		return 1
> > +	fi
> > +}
> > +
> > +EXPECT_PASS()
> > +{
> > +	_tst_expect_pass tst_res "$@"
> > +}
> > +
> > +EXPECT_PASS_BRK()
> > +{
> > +	_tst_expect_pass tst_brk "$@"
> > +}

> I'm not sure that adding the PASS_BRK and FAIL_BRK is a good idea. I
> would stick to simple EXPECT_PASS and EXPECT_FAIL. And maybe we can
> export TST_PASS variable as we do in C to match the API. I think that
> the closer the C and shell API are the better.

C API usually returns on if (!TST_PASS). I don't like it either, but it cannot
be shortened much as we don't use functions but macros.

But changing the code in the shell API does not look to me an improvement:

-EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
+EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
+[ "$TST_PASS" = 1 ] || tst_brk "Quit due the above error"

But OTOH maybe route-change-*.sh tests even don't need to quit.
And it's a question if isofs.sh does (and whether we should even keep isofs.sh).
=> I'm ok with it.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh

[Cyril Hrubis]

Hi!
> > SAFE instead so that the name is closer to the SAFE_XXX macros in C.
> 
> Makes sense. I was even thinking on SAFE_CMD, but we use tst_rod.c, not
> tst_cmd.c. OTOH it was obvious that ROD uses tst_rod.c, should it be also
> renamed? What ROD means anyway? run or dye?

Run or die (we are not coloring anything).

And yes it would make sense to rename tst_rod.c to tst_safe_cmd.c or
similar.

> > > +_tst_expect_pass()
> > > +{
> > > +	local fnc="$1"
> > > +	shift
> > > +
> > > +	tst_rod "$@"
> 
> > If I remmeber correctly the whole reason why we introduced tst_rod.c was
> > that passing the $@ like this causes the $@ to be evaluated twice and
> > produces unexpected results.
> 
> FYI code is copy pasted from tst_test.sh. What do you want me to change?

I've spend a couple of minutes figuring out why we originaly implemented
ROD_BASE() in C.

The problem is that single quotes gets removed as soon as we pass the
parameter.

E.g.: ROD awk '{ print $1 }'

Once we pass that to a shell function the '' disappear, they managed to
keep the { print $1 } to be a single parameter in the list but they are
not there anymore.

And since we were manipulating the parameter list we got, we failed to
reconstruct it correctly in shell since in the next step the { print $1 }
breaks into four separate strings.

As long as we pass the $@ as a whole (even after shift), it does work
since the boundaries of parameters in $@ stay exactly as they were.

TL;DR; The code you copy&pasted is correct, I only misremembered what
was the problem back then.

> > I'm not sure that adding the PASS_BRK and FAIL_BRK is a good idea. I
> > would stick to simple EXPECT_PASS and EXPECT_FAIL. And maybe we can
> > export TST_PASS variable as we do in C to match the API. I think that
> > the closer the C and shell API are the better.
> 
> C API usually returns on if (!TST_PASS). I don't like it either, but it cannot
> be shortened much as we don't use functions but macros.
> 
> But changing the code in the shell API does not look to me an improvement:
> 
> -EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
> +EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
> +[ "$TST_PASS" = 1 ] || tst_brk "Quit due the above error"

Let's keep it then.

> But OTOH maybe route-change-*.sh tests even don't need to quit.
> And it's a question if isofs.sh does (and whether we should even keep isofs.sh).

For the isofs I would probably generate the iso filesystems in advance
and store them in git so that we don't have to re-generate them during
the test run. Other than that mounting an iso filesystem over loopback
and checking that the files are there (which the test does not do) is
valid kernel test. But that is a different problem.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh

[Petr Vorel]

Hi Cyril,

> Hi!
> > > SAFE instead so that the name is closer to the SAFE_XXX macros in C.

> > Makes sense. I was even thinking on SAFE_CMD, but we use tst_rod.c, not
> > tst_cmd.c. OTOH it was obvious that ROD uses tst_rod.c, should it be also
> > renamed? What ROD means anyway? run or dye?

> Run or die (we are not coloring anything).

> And yes it would make sense to rename tst_rod.c to tst_safe_cmd.c or
> similar.

+1, I'll do in next version.

> > > > +_tst_expect_pass()
> > > > +{
> > > > +	local fnc="$1"
> > > > +	shift
> > > > +
> > > > +	tst_rod "$@"

> > > If I remmeber correctly the whole reason why we introduced tst_rod.c was
> > > that passing the $@ like this causes the $@ to be evaluated twice and
> > > produces unexpected results.

> > FYI code is copy pasted from tst_test.sh. What do you want me to change?

> I've spend a couple of minutes figuring out why we originaly implemented
> ROD_BASE() in C.

> The problem is that single quotes gets removed as soon as we pass the
> parameter.

> E.g.: ROD awk '{ print $1 }'

> Once we pass that to a shell function the '' disappear, they managed to
> keep the { print $1 } to be a single parameter in the list but they are
> not there anymore.

Yeah, I've found this shell limitation in the past as well.

> And since we were manipulating the parameter list we got, we failed to
> reconstruct it correctly in shell since in the next step the { print $1 }
> breaks into four separate strings.

> As long as we pass the $@ as a whole (even after shift), it does work
> since the boundaries of parameters in $@ stay exactly as they were.

> TL;DR; The code you copy&pasted is correct, I only misremembered what
> was the problem back then.

Good, I was worried it was something else needed to be fixed. Thanks for double
checking!

> > > I'm not sure that adding the PASS_BRK and FAIL_BRK is a good idea. I
> > > would stick to simple EXPECT_PASS and EXPECT_FAIL. And maybe we can
> > > export TST_PASS variable as we do in C to match the API. I think that
> > > the closer the C and shell API are the better.

> > C API usually returns on if (!TST_PASS). I don't like it either, but it cannot
> > be shortened much as we don't use functions but macros.

> > But changing the code in the shell API does not look to me an improvement:

> > -EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
> > +EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
> > +[ "$TST_PASS" = 1 ] || tst_brk "Quit due the above error"

> Let's keep it then.

+1. We can revisit it later. Anyway, I'll add only what's currently needed,
maybe these network tests will be changed or rewritten into C.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] isofs.sh rewrite [was Re: [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh]

[Petr Vorel]

Hi Cyril,

...
Let's change the mail subject for this.

> > But OTOH maybe route-change-*.sh tests even don't need to quit.
> > And it's a question if isofs.sh does (and whether we should even keep isofs.sh).

> For the isofs I would probably generate the iso filesystems in advance
> and store them in git so that we don't have to re-generate them during
> the test run. Other than that mounting an iso filesystem over loopback
> and checking that the files are there (which the test does not do) is
> valid kernel test. But that is a different problem.

Ah, right. It's both mkisofs/genisoimage/xorrisofs test + testing isofs as the
kernel part :). And sure, isofs itself will kept used for very long time (USB
install media).

I'll create a ticket once we agree what should be done. "Rewrite test to
mounting an iso filesystem over loopback and checking that the files are there."
is clear. Creating filesystem would be gen_fs_tree() calls (these subdirs) +
call one of mkisofs/genisoimage/xorrisofs. I guess TODO is to find out which
options are worth to test. Because test runs various options, testing ISO-9660
(various ISO levels)/JOLIET/UDF. Kernel's fs/isofs/Kconfig mentions
CONFIG_ISO9660_FS and two other depending on it: CONFIG_JOLIET and CONFIG_ZISOFS
(uses an old tool mkzftree).

Resulted ISO file has 9 MB, which is OK for git (given we are ok only with a
single variant). Obviously we are not going to test max files limits (e.g. files
over 2 GB for DVD require iso level 3), but hopefully size does not matter much.

I'm not sure if it's worth to test some invalid ISOs. But it'd be worth to add
max at least test for max file size, i.e recent fix from v7.0-rc1:
18a777eee289 ("isofs: support full length file names (255 instead of 253)")

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH 3/6] shell_loader: Start test count from 1

[Petr Vorel]

tcnt in C library starts from 0. But TST_CNT in tst_test.sh started
from 1. Keep it compatible with the shell code with increasing variable
by one.

Fixes: 5528da0231 ("testcaes/lib: Add shell loader")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
We can go C way (start from 0), but tests will have to be adapted.

 testcases/lib/tst_run_shell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testcases/lib/tst_run_shell.c b/testcases/lib/tst_run_shell.c
index c12361ef5f..ab6f4fda58 100644
--- a/testcases/lib/tst_run_shell.c
+++ b/testcases/lib/tst_run_shell.c
@@ -21,7 +21,7 @@ static void run_shell_tcnt(unsigned int n)
 	char buf[128];
 	char *const params[] = {buf, NULL};
 
-	snprintf(buf, sizeof(buf), "%u", n);
+	snprintf(buf, sizeof(buf), "%u", n+1);
 
 	tst_run_script(shell_filename, params);
 }
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 3/6] shell_loader: Start test count from 1

[Li Wang via ltp]

On Fri, Mar 13, 2026 at 03:25:57PM +0100, Petr Vorel wrote:
> tcnt in C library starts from 0. But TST_CNT in tst_test.sh started
> from 1. Keep it compatible with the shell code with increasing variable
> by one.
> 
> Fixes: 5528da0231 ("testcaes/lib: Add shell loader")
> Signed-off-by: Petr Vorel <pvorel@suse.cz>

Reviewed-by: Li Wang <liwang@redhat.com>

-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [RFC][PATCH 4/6] run_shell_tcnt: Add test count also for test_all

[Petr Vorel]

tst_test.sh shell API has TST_CNT=1 also for tests which are using only
$TST_TESTFUNC without $TST_CNT, i.e. when running only a single
function. Follow this approach. This will be reused in the following
commit.

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Instead of this, we can just check for 1 or empty:
[ "$1" = 1 -o -z "1" ]

 testcases/lib/tst_run_shell.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/testcases/lib/tst_run_shell.c b/testcases/lib/tst_run_shell.c
index ab6f4fda58..6defa9f7e7 100644
--- a/testcases/lib/tst_run_shell.c
+++ b/testcases/lib/tst_run_shell.c
@@ -11,11 +11,6 @@
 
 static char *shell_filename;
 
-static void run_shell(void)
-{
-	tst_run_script(shell_filename, NULL);
-}
-
 static void run_shell_tcnt(unsigned int n)
 {
 	char buf[128];
@@ -26,6 +21,11 @@ static void run_shell_tcnt(unsigned int n)
 	tst_run_script(shell_filename, params);
 }
 
+static void run_shell(void)
+{
+	run_shell_tcnt(0);
+}
+
 static struct tst_test test = {
 	.runs_script = 1,
 };
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [RFC][PATCH 4/6] run_shell_tcnt: Add test count also for test_all

[Li Wang via ltp]

On Fri, Mar 13, 2026 at 03:25:58PM +0100, Petr Vorel wrote:
> tst_test.sh shell API has TST_CNT=1 also for tests which are using only
> $TST_TESTFUNC without $TST_CNT, i.e. when running only a single
> function. Follow this approach. This will be reused in the following
> commit.
> 
> Signed-off-by: Petr Vorel <pvorel@suse.cz>

This is nice work!

Reviewed-by: Li Wang <liwang@redhat.com>

-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Petr Vorel]

Both C API and tst_test.sh shell API run test only once.
Fix shell loader API also to run setup only once.
This reuses functionality added in the previous commit.

Fixes: 8202494493 ("shell lib: Add basic support for test setup")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
NOTE: this is still not working on iterations (-i2), because
static int iterations is from tst_test.c is not propagated to
tst_run_shell.c. I wonder if I should set the value as environment
variable or add it into struct context.

 testcases/lib/tst_run.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testcases/lib/tst_run.sh b/testcases/lib/tst_run.sh
index e876fd8946..b78c7be03a 100644
--- a/testcases/lib/tst_run.sh
+++ b/testcases/lib/tst_run.sh
@@ -15,7 +15,7 @@ fi
 
 if [ -n "$TST_SETUP" ]; then
 	if command -v $TST_SETUP >/dev/null 2>/dev/null; then
-		$TST_SETUP
+		[ "$1" != 1 ] || $TST_SETUP
 	else
 		tst_brk TBROK "TST_SETUP=$TST_SETUP declared, but function not defined (or cmd not found)"
 	fi
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Li Wang via ltp]

On Fri, Mar 13, 2026 at 03:25:59PM +0100, Petr Vorel wrote:
> Both C API and tst_test.sh shell API run test only once.
> Fix shell loader API also to run setup only once.
> This reuses functionality added in the previous commit.
> 
> Fixes: 8202494493 ("shell lib: Add basic support for test setup")
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> NOTE: this is still not working on iterations (-i2), because
> static int iterations is from tst_test.c is not propagated to
> tst_run_shell.c. I wonder if I should set the value as environment
> variable or add it into struct context.

Passing the current iteration as env variable is feasible.

Since LTP export an similar variable 'TST_ITERATIONS' in tst_test.sh,
maybe define another env var for current loop, e.g. TST_ITERATION
(or TST_CURRENT_LOOP), pass to tst_run.sh?

Something like:

1. Create tst_get_cur_iteration(void) function in LTP core API

2. Export current loop in tst_run_shell.c before running run_shell_tcnt()

  static void run_shell_tcnt(unsigned int n)
  {
    ...
    char iter_buf[32];
    
    snprintf(iter_buf, sizeof(iter_buf), "%u", tst_get_cur_iteration());
    
    if (setenv("TST_ITERATION", iter_buf, 1))
    	tst_brk(TBROK | TERRNO, "setenv(TST_ITERATION) failed");
    
    tst_run_script(shell_filename, params);
  }

3. Reuse it in tst_run.sh to run setup once globally

  [ "$1" == "1" ] && [ "${TST_ITERATION:-1}" == "1" ] && $TST_SETUP


-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Cyril Hrubis]

Hi!
> > NOTE: this is still not working on iterations (-i2), because
> > static int iterations is from tst_test.c is not propagated to
> > tst_run_shell.c. I wonder if I should set the value as environment
> > variable or add it into struct context.
> 
> Passing the current iteration as env variable is feasible.
> 
> Since LTP export an similar variable 'TST_ITERATIONS' in tst_test.sh,
> maybe define another env var for current loop, e.g. TST_ITERATION
> (or TST_CURRENT_LOOP), pass to tst_run.sh?
> 
> Something like:
> 
> 1. Create tst_get_cur_iteration(void) function in LTP core API
> 
> 2. Export current loop in tst_run_shell.c before running run_shell_tcnt()
> 
>   static void run_shell_tcnt(unsigned int n)
>   {
>     ...
>     char iter_buf[32];
>     
>     snprintf(iter_buf, sizeof(iter_buf), "%u", tst_get_cur_iteration());
>     
>     if (setenv("TST_ITERATION", iter_buf, 1))
>     	tst_brk(TBROK | TERRNO, "setenv(TST_ITERATION) failed");
>     
>     tst_run_script(shell_filename, params);
>   }
> 
> 3. Reuse it in tst_run.sh to run setup once globally
> 
>   [ "$1" == "1" ] && [ "${TST_ITERATION:-1}" == "1" ] && $TST_SETUP

It's a bit more complicated we do not have only iterations but also
duration and timeout per iteration. So we would need a function that
would return if the script should continue or not and also call the
heartbeat() function. Something as:

int tst_next_shell_iteration(void)
{
	int cont = 0;
	static int iteration = 0;

	if (iteration < iterations)
		cont = 1;

	if (stop_time && get_time_ms() < stop_time())
		cont = 1;

	if (!cont)
		return 0;

	heartbeat();
	return ++iteration;
}

The shell helper would call this and we would use it in tst_run.sh and
loop the tst_test() until we are said to stop.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Cyril Hrubis]

Hi!
> It's a bit more complicated we do not have only iterations but also
> duration and timeout per iteration. So we would need a function that
> would return if the script should continue or not and also call the
> heartbeat() function. Something as:
> 
> int tst_next_shell_iteration(void)
> {
> 	int cont = 0;
> 	static int iteration = 0;
> 
> 	if (iteration < iterations)
> 		cont = 1;
> 
> 	if (stop_time && get_time_ms() < stop_time())
> 		cont = 1;
> 
> 	if (!cont)
> 		return 0;
> 
> 	heartbeat();
> 	return ++iteration;
> }
> 
> The shell helper would call this and we would use it in tst_run.sh and
> loop the tst_test() until we are said to stop.

Note also that this solution would move the iteration into the shell
script, since if we do not iterate in the shell, we will end up with a
different environment in the second and subsequent iterations. That
means that any variables exported in setup() would be lost in subsequent
iterations, the pid of the shell would be different, etc.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Petr Vorel]

Hi Cyril,

> Hi!
> > It's a bit more complicated we do not have only iterations but also
> > duration and timeout per iteration. So we would need a function that
> > would return if the script should continue or not and also call the
> > heartbeat() function. Something as:

> > int tst_next_shell_iteration(void)
> > {
> > 	int cont = 0;
> > 	static int iteration = 0;

> > 	if (iteration < iterations)
> > 		cont = 1;

> > 	if (stop_time && get_time_ms() < stop_time())
> > 		cont = 1;

> > 	if (!cont)
> > 		return 0;

> > 	heartbeat();
> > 	return ++iteration;
> > }

> > The shell helper would call this and we would use it in tst_run.sh and
> > loop the tst_test() until we are said to stop.

Wait, tst_run_shell.c calls shell script via tst_run_script(). This can be
called only once, before starting the script...

> Note also that this solution would move the iteration into the shell

... but from the code it's obvious that you want to call it more times.
How do you want to reach C library code from shell test?

> script, since if we do not iterate in the shell, we will end up with a
> different environment in the second and subsequent iterations. That
> means that any variables exported in setup() would be lost in subsequent
> iterations, the pid of the shell would be different, etc.

Yes, I noticed that during du01.sh rewrite. I was surprised but thought that you
wanted to have most of the library code be in C API (having shell part of the
shell loader really thin).

Before sending the patchset I was thinking if some shell variables should be
shared and exported into new shell run. But it'd be unpractical and as you write
PID of the shell would be always different.

I have to admit sometimes I think whether rewriting everything into C wouldn't
be a better time investment than implementing shell loader, given we are going
to redesign network API. Anyway, any new test should really be using C API.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Cyril Hrubis]

Hi!
> > > It's a bit more complicated we do not have only iterations but also
> > > duration and timeout per iteration. So we would need a function that
> > > would return if the script should continue or not and also call the
> > > heartbeat() function. Something as:
> 
> > > int tst_next_shell_iteration(void)
> > > {
> > > 	int cont = 0;
> > > 	static int iteration = 0;
> 
> > > 	if (iteration < iterations)
> > > 		cont = 1;
> 
> > > 	if (stop_time && get_time_ms() < stop_time())
> > > 		cont = 1;
> 
> > > 	if (!cont)
> > > 		return 0;
> 
> > > 	heartbeat();
> > > 	return ++iteration;
> > > }
> 
> > > The shell helper would call this and we would use it in tst_run.sh and
> > > loop the tst_test() until we are said to stop.
> 
> Wait, tst_run_shell.c calls shell script via tst_run_script(). This can be
> called only once, before starting the script...

The tst_run_script() is set as the tst_test.test or tst_test.test_all
function. Then we enter the library via the tst_run_tcases() and we do
the full test library init and everything.

The problem with that is that we run the shell script is re-executed
for each -i iteration. That means that unlike the fork() the whole
environment is re-created. So we cannot run setup() only for first
iteration as we do for C.

So we either call the setup in each iteration (that means both tcnt and
-i) or we push the loop over tcnt and -i into the shell. I think that
more elegant solution is the latter.

> > Note also that this solution would move the iteration into the shell
> 
> ... but from the code it's obvious that you want to call it more times.
> How do you want to reach C library code from shell test?

We would have to just call the tst_test->test() function directly in the
fork_testrun() instead of testrun() for script tests. That would avoid
all the looping and heartbeats() in C library in that case.

> > script, since if we do not iterate in the shell, we will end up with a
> > different environment in the second and subsequent iterations. That
> > means that any variables exported in setup() would be lost in subsequent
> > iterations, the pid of the shell would be different, etc.
> 
> Yes, I noticed that during du01.sh rewrite. I was surprised but thought that you
> wanted to have most of the library code be in C API (having shell part of the
> shell loader really thin).
> 
> Before sending the patchset I was thinking if some shell variables should be
> shared and exported into new shell run. But it'd be unpractical and as you write
> PID of the shell would be always different.
> 
> I have to admit sometimes I think whether rewriting everything into C wouldn't
> be a better time investment than implementing shell loader, given we are going
> to redesign network API. Anyway, any new test should really be using C API.

I think that the shell API is nearly finished at this point, the last
unsolved piece is how we design the test iterations with -i and tcnt.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Petr Vorel]

> Hi!
> > > > It's a bit more complicated we do not have only iterations but also
> > > > duration and timeout per iteration. So we would need a function that
> > > > would return if the script should continue or not and also call the
> > > > heartbeat() function. Something as:

> > > > int tst_next_shell_iteration(void)
> > > > {
> > > > 	int cont = 0;
> > > > 	static int iteration = 0;

> > > > 	if (iteration < iterations)
> > > > 		cont = 1;

> > > > 	if (stop_time && get_time_ms() < stop_time())
> > > > 		cont = 1;

> > > > 	if (!cont)
> > > > 		return 0;

> > > > 	heartbeat();
> > > > 	return ++iteration;
> > > > }

> > > > The shell helper would call this and we would use it in tst_run.sh and
> > > > loop the tst_test() until we are said to stop.

> > Wait, tst_run_shell.c calls shell script via tst_run_script(). This can be
> > called only once, before starting the script...

> The tst_run_script() is set as the tst_test.test or tst_test.test_all
> function. Then we enter the library via the tst_run_tcases() and we do
> the full test library init and everything.

> The problem with that is that we run the shell script is re-executed
> for each -i iteration. That means that unlike the fork() the whole
> environment is re-created. So we cannot run setup() only for first
> iteration as we do for C.

> So we either call the setup in each iteration (that means both tcnt and
> -i) or we push the loop over tcnt and -i into the shell. I think that
> more elegant solution is the latter.

Agree.

> > > Note also that this solution would move the iteration into the shell

> > ... but from the code it's obvious that you want to call it more times.
> > How do you want to reach C library code from shell test?

> We would have to just call the tst_test->test() function directly in the
> fork_testrun() instead of testrun() for script tests. That would avoid
> all the looping and heartbeats() in C library in that case.

+1. My question was answered by "use C helper to read iteration from shared
memory".

> > > script, since if we do not iterate in the shell, we will end up with a
> > > different environment in the second and subsequent iterations. That
> > > means that any variables exported in setup() would be lost in subsequent
> > > iterations, the pid of the shell would be different, etc.

> > Yes, I noticed that during du01.sh rewrite. I was surprised but thought that you
> > wanted to have most of the library code be in C API (having shell part of the
> > shell loader really thin).

> > Before sending the patchset I was thinking if some shell variables should be
> > shared and exported into new shell run. But it'd be unpractical and as you write
> > PID of the shell would be always different.

> > I have to admit sometimes I think whether rewriting everything into C wouldn't
> > be a better time investment than implementing shell loader, given we are going
> > to redesign network API. Anyway, any new test should really be using C API.

> I think that the shell API is nearly finished at this point, the last
> unsolved piece is how we design the test iterations with -i and tcnt.

We need also getopts which we will also have to be handled in shell because we
actually execute the shell. Then timeout handling (LTP_TIMEOUT_MUL, LTP_RUNTIME_MUL),
but that should be part of the function you suggested for iteration.

Hopefully that's all and shell loader will be kept thin, but you know, the devil
is hidden in detail.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH 6/6] du01.sh: Rewrite into shell loader

[Petr Vorel]

While at it, simplify variables: ${VAR} => $VAR

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
 testcases/commands/du/du01.sh | 88 +++++++++++++++++++++--------------
 1 file changed, 54 insertions(+), 34 deletions(-)

diff --git a/testcases/commands/du/du01.sh b/testcases/commands/du/du01.sh
index 7cdb98ca16..6a51a9d0b3 100755
--- a/testcases/commands/du/du01.sh
+++ b/testcases/commands/du/du01.sh
@@ -1,15 +1,36 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright (c) 2026 Petr Vorel <pvorel@suse.cz>
 # Copyright (c) 2015 Fujitsu Ltd.
 # Author: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
 #
+# ---
+# doc
 # Test du command with some basic options.
+# ---
+#
+# ---
+# env
+# {
+#  "tcnt": 23,
+#  "needs_tmpdir": true,
+#  "needs_cmds": [
+#     {
+#       "cmd": "dd"
+#     },
+#     {
+#       "cmd": "du"
+#     },
+#     {
+#       "cmd": "stat"
+#     }
+#  ]
+# }
+# ---
+
+. tst_loader.sh
 
-TST_CNT=23
 TST_SETUP=setup
-TST_TESTFUNC=do_test
-TST_NEEDS_TMPDIR=1
-TST_NEEDS_CMDS="dd du stat"
 
 setup()
 {
@@ -17,10 +38,9 @@ setup()
 	cd basedir || tst_brk TBROK "cd basedir failed"
 
 	ROD_SILENT dd if=/dev/zero of=testfile bs=1M count=10
-
 	ROD_SILENT mkdir -p testdir
-
 	ROD_SILENT ln -s ../testfile testdir/testsymlink
+	cd ..
 
 	# Display values are in units of the first available SIZE
 	# from --block-size, and the DU_BLOCK_SIZE, BLOCK_SIZE and
@@ -34,12 +54,13 @@ setup()
 
 du_test()
 {
+	cd basedir || tst_brk TBROK "cd basedir failed"
 	local test_return
 
 	$1 > ../temp 2>&1
 	test_return=$?
 
-	if [ ${test_return} -ne 0 ]; then
+	if [ $test_return -ne 0 ]; then
 		grep -q -E "unrecognized option|invalid option" ../temp
 		if [ $? -eq 0 ]; then
 			tst_res TCONF "'$1' not supported"
@@ -69,7 +90,7 @@ block_size=$((block_size / 1024))
 # So we use the approximate value to check.
 check1="^10[2-3][0-9][0-9][[:space:]]\."
 check2="^10[2-3][0-9][0-9][[:space:]]testfile"
-check3="^\(0\|${block_size}\)[[:space:]]\./testdir/testsymlink"
+check3="^\(0\|$block_size\)[[:space:]]\./testdir/testsymlink"
 check5="^20[4-6][0-9][0-9][[:space:]]\."
 check7="^10[4-5][0-9][0-9]\{4\}[[:space:]]\."
 check9="^10[2-3][0-9][0-9][[:space:]]total"
@@ -79,34 +100,33 @@ check16="^10[2-3][0-9][0-9][[:space:]]testdir/"
 check20="^11M[[:space:]]\."
 check23="^[0-9]\{1,2\}[[:space:]]\."
 
-do_test()
+tst_test()
 {
 	case $1 in
-	1) du_test "du" ${check1};;
-	2) du_test "du testfile" ${check2};;
-	3) du_test "du -a" ${check3};;
-	4) du_test "du --all" ${check3};;
-	5) du_test "du -B ${block_size_default}" ${check5};;
-	6) du_test "du --block-size=${block_size_default}" ${check5};;
-	7) du_test "du -b" ${check7};;
-	8) du_test "du --bytes" ${check7};;
-	9) du_test "du -c" ${check9};;
-	10) du_test "du --total" ${check9};;
-	11) du_test "du -D testdir/testsymlink" ${check11};;
-	12) du_test "du --dereference-args testdir/testsymlink" ${check11};;
-	13) du_test "du --max-depth=1" ${check1};;
-	14) du_test "du --human-readable" ${check14};;
-	15) du_test "du -k" ${check1};;
-	16) du_test "du -L testdir/" ${check16};;
-	17) du_test "du --dereference testdir/" ${check16};;
-	18) du_test "du -P" ${check1};;
-	19) du_test "du --no-dereference" ${check1};;
-	20) du_test "du --si" ${check20};;
-	21) du_test "du -s" ${check1};;
-	22) du_test "du --summarize" ${check1};;
-	23) du_test "du --exclude=testfile" ${check23};;
+	1) du_test "du" $check1;;
+	2) du_test "du testfile" $check2;;
+	3) du_test "du -a" $check3;;
+	4) du_test "du --all" $check3;;
+	5) du_test "du -B $block_size_default" $check5;;
+	6) du_test "du --block-size=$block_size_default" $check5;;
+	7) du_test "du -b" $check7;;
+	8) du_test "du --bytes" $check7;;
+	9) du_test "du -c" $check9;;
+	10) du_test "du --total" $check9;;
+	11) du_test "du -D testdir/testsymlink" $check11;;
+	12) du_test "du --dereference-args testdir/testsymlink" $check11;;
+	13) du_test "du --max-depth=1" $check1;;
+	14) du_test "du --human-readable" $check14;;
+	15) du_test "du -k" $check1;;
+	16) du_test "du -L testdir/" $check16;;
+	17) du_test "du --dereference testdir/" $check16;;
+	18) du_test "du -P" $check1;;
+	19) du_test "du --no-dereference" $check1;;
+	20) du_test "du --si" $check20;;
+	21) du_test "du -s" $check1;;
+	22) du_test "du --summarize" $check1;;
+	23) du_test "du --exclude=testfile" $check23;;
 	esac
 }
 
-. tst_test.sh
-tst_run
+. tst_run.sh
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp