Mailing List Archive

[PATCH 3/4] selftests/nolibc: always print the log file
This allows to check the other issues of the output file manually even
when all of them passed.

Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
---
tools/testing/selftests/nolibc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index 5b0af8d8f5f3..518f85c77fe3 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -130,7 +130,7 @@ libc-test: nolibc-test.c
test-report:
$(Q)[ -f $(CURDIR)/run.out ] && awk '/\[OK\]$$/{p++} /\[FAIL\]$$/{f++} /\[SKIPPED\]$$/{s++} \
END{ printf("%d test(s) passed, %d skipped, %d failed.", p, s, f); \
- if (s+f > 0) printf(" See all results in %s\n", ARGV[1]); else print; }' \
+ printf(" See all results in %s\n", ARGV[1]); }' \
$(CURDIR)/run.out || :

# qemu user-land test
--
2.25.1
Re: [PATCH 3/4] selftests/nolibc: always print the log file [ In reply to ]
On Mon, Jun 05, 2023 at 11:57:44AM +0800, Zhangjin Wu wrote:
> This allows to check the other issues of the output file manually even
> when all of them passed.

Till now I preferred not to see it when everything was OK since it was
useless and permitted a quick visual check in the reports. Do you
really think it's useful ? If others prefer it that way we can change
it but I purposely added this test to "improve" the output (for me at
least). I'm interested in opinions here.

Willy
Re: [PATCH 3/4] selftests/nolibc: always print the log file [ In reply to ]
> On Mon, Jun 05, 2023 at 11:57:44AM +0800, Zhangjin Wu wrote:
> > This allows to check the other issues of the output file manually even
> > when all of them passed.
>
> Till now I preferred not to see it when everything was OK since it was
> useless and permitted a quick visual check in the reports. Do you
> really think it's useful ? If others prefer it that way we can change
> it but I purposely added this test to "improve" the output (for me at
> least). I'm interested in opinions here.
>

I planed to add detailed potential issues to check in the commit
message, but didn't do that eventually.

The potential 'issues' may be:

1. string alignment, I found one character offset in the user-space
'efault' handler patchset
2. duplicated print, the one like '30 fork' we have fixed up
3. kernel messages (may provide some important info)

I did add this manually several times in the past weeks, so, if the path
is there, I can simply copy it and cat it, hope we can print the path by
default ;-)

The commit message may be changed to something like this:

This allows us to check the details in the log file even when all of
them passed, from the log details, we can check the string
alignment, duplicated print and kernel messages.

Best regards,
Zhangjin

> Willy