[PATCH 1/4] selftests/nolibc: add a test-report target
Zhangjin Wu
falcon at tinylab.org
Wed Jun 7 07:15:02 PDT 2023
On Wed, Jun 07, 2023 at 01:52:00PM +0800, Zhangjin Wu wrote:
> > Hi, Willy
> >
> (...)
> > >
> > > Ok, thanks, what about this?
> > >
> > > # LOG_REPORT: report the test results
> > > LOG_REPORT := awk '/\[OK\][\r]*$$/{p++} /\[FAIL\][\r]*$$/{f++} /\[SKIPPED\][\r]*$$/{s++} \
> > > END{ printf("%d test(s) passed, %d skipped, %d failed.", p, s, f); \
> > > printf(" See all results in %s\n", ARGV[1]); }'
> > >
> > > run-user: nolibc-test
> > > $(Q)qemu-$(QEMU_ARCH) ./nolibc-test > "$(CURDIR)/run.out" || :
> > > $(Q)$(LOG_REPORT) $(CURDIR)/run.out
> > >
> > > run: kernel
> > > $(Q)qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(srctree)/$(IMAGE)" -serial stdio $(QEMU_ARGS) > "$(CURDIR)/run.out"
> > > $(Q)$(LOG_REPORT) $(CURDIR)/run.out
> > >
> > > rerun:
> > > $(Q)qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(srctree)/$(IMAGE)" -serial stdio $(QEMU_ARGS) > "$(CURDIR)/run.out"
> > > $(Q)$(LOG_REPORT) $(CURDIR)/run.out
> > >
> > > Or we directly add a standalone test report script? something like
> > > tools/testing/selftests/nolibc/report.sh
> > >
> > > #!/bin/sh
> > > #
> > > # report.sh -- report the test results of nolibc-test
> > > #
> > >
> > > LOG_FILE=$1
> > > [ ! -f "$LOG_FILE" ] && echo "Usage: $0 /path/to/run.out"
> > >
> > > awk '
> > > /\[OK\][\r]*$$/{ p++ }
> > > /\[FAIL\][\r]*$$/{ f++ }
> > > /\[SKIPPED\][\r]*$$/{ s++ }
> > >
> > > END {
> > > printf("%d test(s) passed, %d skipped, %d failed.", p, s, f);
> > > printf(" See all results in %s\n", ARGV[1]);
> > > }' $LOG_FILE
> > >
> > > And use it like this:
> > >
> > > LOG_REPORT = $(CURDIR)/report.sh
> > >
> >
> > I plan to renew this patchset, which one of the above methods do you
> > prefer?
>
> IFF it needs to be done I prefer the macro in the Makefile to avoid
> depending on external scripts that are useless outside of the makefile.
> BUT, my point remains that I adopted this so that I could quickly and
> visually check that everything was OK. I'm fine with any other method
> but I do not want to have to carefully read all these lines to make
> sure I'm not mixing a "8" with a "0" (I'm mentioning this one because
> it's exactly the one I had when I decided to add the extra values).
> For example if you prepend "FAILURE: ", "WARNING: ", "SUCCESS: " in
> front of these lines to summarize them depending on the highest level
> encountered (success, skipped, failed), then I'm fine because it's
> easy to check that all lines show the same word.
>
Ok.
> > For the always print statement:
> >
> > printf(" See all results in %s\n", ARGV[1]); }'
>
> Then please put it on its own line without the leading space, this
> will be even more readable.
>
It is a good balance.
This may be more useful if we run this from the kselftest framework,
seems it is not able to run it from the 'kselftest' target currently,
here shares something I have tried:
I tried something like this, seems run-user works, but defconfig and run
not.
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index 4a3a105e1fdf..70693f6501c6 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -83,6 +83,8 @@ CFLAGS ?= -Os -fno-ident -fno-asynchronous-unwind-tables -std=c89 \
$(CFLAGS_$(ARCH)) $(CFLAGS_STACKPROTECTOR)
LDFLAGS := -s
+NOLIBC_SUBTARGETS ?= run-user
+
help:
@echo "Supported targets under selftests/nolibc:"
@echo " all call the \"run\" target below"
@@ -110,7 +112,9 @@ help:
@echo " IMAGE_NAME = $(if $(IMAGE_NAME),$(IMAGE_NAME),UNKNOWN_ARCH) [determined from \$$ARCH]"
@echo ""
-all: run
+run_tests: $(NOLIBC_SUBTARGETS)
+
+all: $(NOLIBC_SUBTARGETS)
This can be triggered from the top-level kselftest framework:
$ make -C /path/to/linux-stable kselftest TARGETS=nolibc NOLIBC_SUBTARGETS=run-user
And seems we still not support O= currently either.
> > I will paste the reason why I need it, as mentioned in [1], if you still
> > need a clean test report, I will give up this change ;-)
>
> No worries, I don't want to be annoying if you need something, but I
> don't want to be annoyed by changes either :-)
>
Thanks,
Zhangjin
> thanks,
> Willy
More information about the linux-riscv
mailing list