With the out-of-tree builds it's possible do incremental tests fairly fast:
$ time ./run-tests.sh i386: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success x86_64: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success arm64: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success arm: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success mips: 160 test(s): 159 passed, 1 skipped, 0 failed => status: warning ppc: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success ppc64: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success ppc64le: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success riscv: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success s390: 160 test(s): 159 passed, 1 skipped, 0 failed => status: warning loongarch: 160 test(s): 159 passed, 1 skipped, 0 failed => status: warning
real 3m11.735s user 4m20.354s sys 1m11.880s
This is with an incremental kernel rebuild and testrun inside qemu.
Note:
"selftests/nolibc: use qemu-system-ppc64 also for ppc64le" was already submitted standalone but I included it here again for easier testing and review.
Signed-off-by: Thomas Weißschuh linux@weissschuh.net --- Thomas Weißschuh (5): selftests/nolibc: use qemu-system-ppc64 also for ppc64le selftests/nolibc: use EFI -bios for LoongArch qemu selftests/nolibc: anchor paths in $(srcdir) if possible selftests/nolibc: support out-of-tree builds selftests/nolibc: generate config automatically
tools/testing/selftests/nolibc/Makefile | 36 +++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 13 deletions(-) --- base-commit: d423dcd4ac21041618ab83455c09440d76dbc099 change-id: 20231010-nolibc-out-of-tree-b6684c6cf0e3
Best regards,
qemu-system-ppc64 can handle both big and little endian kernels.
While some setups, like Debian, provide a symlink to execute qemu-system-ppc64 as qemu-system-ppc64le, others, like ArchLinux, do not.
So always use qemu-system-ppc64 directly.
Signed-off-by: Thomas Weißschuh linux@weissschuh.net --- 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 891aa396163d..af60e07d3c12 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -82,7 +82,7 @@ QEMU_ARCH_arm = arm QEMU_ARCH_mips = mipsel # works with malta_defconfig QEMU_ARCH_ppc = ppc QEMU_ARCH_ppc64 = ppc64 -QEMU_ARCH_ppc64le = ppc64le +QEMU_ARCH_ppc64le = ppc64 QEMU_ARCH_riscv = riscv64 QEMU_ARCH_s390 = s390x QEMU_ARCH_loongarch = loongarch64
qemu for LoongArch does not work properly with direct kernel boot. The kernel will panic during initialization and hang without any output.
When booting in EFI mode everything work correctly.
While users most likely don't have the LoongArch EFI binary installed at least an explicit error about 'file not found' is better than a hanging test without output that can never succeed.
Link: https://lore.kernel.org/loongarch/1738d60a-df3a-4102-b1da-d16a29b6e06a@t-8ch... Signed-off-by: Thomas Weißschuh linux@weissschuh.net
--- Note: I'm wondering how this worked for anybody else. --- 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 af60e07d3c12..258293639572 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -100,7 +100,7 @@ QEMU_ARGS_ppc64 = -M powernv -append "console=hvc0 panic=-1 $(TEST:%=NOLIBC QEMU_ARGS_ppc64le = -M powernv -append "console=hvc0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_riscv = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_s390 = -M s390-ccw-virtio -m 1G -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" -QEMU_ARGS_loongarch = -M virt -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)" +QEMU_ARGS_loongarch = -M virt -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)" -bios /usr/share/edk2/loongarch64/OVMF_CODE.fd QEMU_ARGS = $(QEMU_ARGS_$(XARCH)) $(QEMU_ARGS_EXTRA)
# OUTPUT is only set when run from the main makefile, otherwise
Hi Thomas,
On Tue, Oct 10, 2023 at 02:33:57PM +0200, Thomas Weißschuh wrote:
qemu for LoongArch does not work properly with direct kernel boot. The kernel will panic during initialization and hang without any output.
When booting in EFI mode everything work correctly.
While users most likely don't have the LoongArch EFI binary installed at least an explicit error about 'file not found' is better than a hanging test without output that can never succeed.
Agreed. Let's hope at least users will be able to figure what's missing depending on the message. There's one thing, though, you hard-coded the path to the file system, and it's unlikely to be located at the same place for everyone:
-bios /usr/share/edk2/loongarch64/OVMF_CODE.fd
Sure, it's also possible to force QEMU_ARGS but it's becoming complicated due to the numerous arguments. Maybe use a QEMU_BIOS_loongarch variable for this ? This way if this starts to generalize to other archs, we can later simplify it and automatically append -bios when needed.
Link: https://lore.kernel.org/loongarch/1738d60a-df3a-4102-b1da-d16a29b6e06a@t-8ch... Signed-off-by: Thomas Weißschuh linux@weissschuh.net
Note: I'm wondering how this worked for anybody else.
Not much surprised. As I mentioned, my qemu currently doesn't support loongarch so I didn't boot that one. Maybe Zhangjin had this one as part of his other patches.
Overall, on the principle, Acked-by: Willy Tarreau w@1wt.eu
Thanks! Willy
Oct 22, 2023 11:21:16 Willy Tarreau w@1wt.eu:
On Tue, Oct 10, 2023 at 02:33:57PM +0200, Thomas Weißschuh wrote:
qemu for LoongArch does not work properly with direct kernel boot. The kernel will panic during initialization and hang without any output.
When booting in EFI mode everything work correctly.
While users most likely don't have the LoongArch EFI binary installed at least an explicit error about 'file not found' is better than a hanging test without output that can never succeed.
Agreed. Let's hope at least users will be able to figure what's missing depending on the message. There's one thing, though, you hard-coded the path to the file system, and it's unlikely to be located at the same place for everyone:
-bios /usr/share/edk2/loongarch64/OVMF_CODE.fd
Sure, it's also possible to force QEMU_ARGS but it's becoming complicated due to the numerous arguments. Maybe use a QEMU_BIOS_loongarch variable for this ? This way if this starts to generalize to other archs, we can later simplify it and automatically append -bios when needed.
My hope was for it to be a purely temporary bandaid. But you are right, let's do it properly from the beginning.
Link: https://lore.kernel.org/loongarch/1738d60a-df3a-4102-b1da-d16a29b6e06a@t-8ch... Signed-off-by: Thomas Weißschuh linux@weissschuh.net
Note: I'm wondering how this worked for anybody else.
Not much surprised. As I mentioned, my qemu currently doesn't support loongarch so I didn't boot that one. Maybe Zhangjin had this one as part of his other patches.
Overall, on the principle, Acked-by: Willy Tarreau w@1wt.eu
Thanks!
On Tue, Oct 24, 2023 at 06:06:11PM +0200, Thomas Weißschuh wrote:
Oct 22, 2023 11:21:16 Willy Tarreau w@1wt.eu:
On Tue, Oct 10, 2023 at 02:33:57PM +0200, Thomas Weißschuh wrote:
qemu for LoongArch does not work properly with direct kernel boot. The kernel will panic during initialization and hang without any output.
When booting in EFI mode everything work correctly.
While users most likely don't have the LoongArch EFI binary installed at least an explicit error about 'file not found' is better than a hanging test without output that can never succeed.
Agreed. Let's hope at least users will be able to figure what's missing depending on the message. There's one thing, though, you hard-coded the path to the file system, and it's unlikely to be located at the same place for everyone:
-bios /usr/share/edk2/loongarch64/OVMF_CODE.fd
Sure, it's also possible to force QEMU_ARGS but it's becoming complicated due to the numerous arguments. Maybe use a QEMU_BIOS_loongarch variable for this ? This way if this starts to generalize to other archs, we can later simplify it and automatically append -bios when needed.
My hope was for it to be a purely temporary bandaid. But you are right, let's do it properly from the beginning.
The right way to think about temporary code is that if it's supposed to be quick to address, you don't want to introduce a temporary way of proceeding that will change later as the change will annoy some users. And if the reason for the temporary step is a temporary difficulty, you can be certain nobody will ever try to address it and that temporary will be definitive. So thinking "temporary" should generally ring a bell "am I going to annoy users for no reason or am I putting myself in a wrong corner". That's why I really try to avoid anything "temporary". (But there's no problem with making the wrong choice and regretting later, of course ;-)).
Cheers, Willy
It is easier to recognize paths from their well-known location in the source tree than having to resolve the relative path in ones head.
Signed-off-by: Thomas Weißschuh linux@weissschuh.net --- tools/testing/selftests/nolibc/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 258293639572..598d53c5cb7b 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -167,7 +167,7 @@ sysroot: sysroot/$(ARCH)/include sysroot/$(ARCH)/include: $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot $(QUIET_MKDIR)mkdir -p sysroot - $(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone + $(Q)$(MAKE) -C $(srctree)/tools/include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone $(Q)mv sysroot/sysroot sysroot/$(ARCH)
ifneq ($(NOLIBC_SYSROOT),0) @@ -177,7 +177,7 @@ nolibc-test: nolibc-test.c sysroot/$(ARCH)/include else nolibc-test: nolibc-test.c $(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \ - -nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc + -nostdlib -static -include $(srctree)/tools/include/nolibc/nolibc.h $< -lgcc endif
libc-test: nolibc-test.c
On Tue, Oct 10, 2023 at 02:33:58PM +0200, Thomas Weißschuh wrote:
It is easier to recognize paths from their well-known location in the source tree than having to resolve the relative path in ones head.
Signed-off-by: Thomas Weißschuh linux@weissschuh.net
tools/testing/selftests/nolibc/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 258293639572..598d53c5cb7b 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -167,7 +167,7 @@ sysroot: sysroot/$(ARCH)/include sysroot/$(ARCH)/include: $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot $(QUIET_MKDIR)mkdir -p sysroot
- $(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone
- $(Q)$(MAKE) -C $(srctree)/tools/include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone $(Q)mv sysroot/sysroot sysroot/$(ARCH)
ifneq ($(NOLIBC_SYSROOT),0) @@ -177,7 +177,7 @@ nolibc-test: nolibc-test.c sysroot/$(ARCH)/include else nolibc-test: nolibc-test.c $(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \
-nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc
-nostdlib -static -include $(srctree)/tools/include/nolibc/nolibc.h $< -lgccendif
Agreed, this comes from the early days where we didn't have srctree, that's better this way.
Acked-by: Willy Tarreau w@1wt.eu
Willy
Out of tree builds are much more convenient when building for multiple architectures or configurations in parallel.
Only absolute O= parameters are supported as Makefile.include will always resolve relative paths in relation to $(srctree) instead of the current directory.
Add a call to "make outputmakefile" to verify that the sourcetree is clean.
This is based on Zhangjins out-of-tree patch. It extends that work for get_init_cpio support and also drops relative O= specifications explicitly.
Link: https://lore.kernel.org/lkml/06d96bd81fe812a9718098a383678ad3beba98b1.169121... Signed-off-by: Thomas Weißschuh linux@weissschuh.net --- tools/testing/selftests/nolibc/Makefile | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 598d53c5cb7b..21e3f7da2ecf 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -1,9 +1,16 @@ # SPDX-License-Identifier: GPL-2.0 # Makefile for nolibc tests include ../../../scripts/Makefile.include +include ../../../scripts/utilities.mak # We need this for the "cc-option" macro. include ../../../build/Build.include
+ifneq ($(O),) +ifneq ($(call is-absolute,$(O)),y) +$(error Only absolute O= parameters are supported) +endif +endif + # we're in ".../tools/testing/selftests/nolibc" ifeq ($(srctree),) srctree := $(patsubst %/tools/testing/selftests/,%,$(dir $(CURDIR))) @@ -14,6 +21,8 @@ include $(srctree)/scripts/subarch.include ARCH = $(SUBARCH) endif
+objtree ?= $(srctree) + # XARCH extends the kernel's ARCH with a few variants of the same # architecture that only differ by the configuration, the toolchain # and the Qemu program used. It is copied as-is into ARCH except for @@ -52,7 +61,7 @@ IMAGE_ppc64le = arch/powerpc/boot/zImage IMAGE_riscv = arch/riscv/boot/Image IMAGE_s390 = arch/s390/boot/bzImage IMAGE_loongarch = arch/loongarch/boot/vmlinuz.efi -IMAGE = $(IMAGE_$(XARCH)) +IMAGE = $(objtree)/$(IMAGE_$(XARCH)) IMAGE_NAME = $(notdir $(IMAGE))
# default kernel configurations that appear to be usable @@ -167,6 +176,7 @@ sysroot: sysroot/$(ARCH)/include sysroot/$(ARCH)/include: $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot $(QUIET_MKDIR)mkdir -p sysroot + $(Q)$(MAKE) -C $(srctree) outputmakefile $(Q)$(MAKE) -C $(srctree)/tools/include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone $(Q)mv sysroot/sysroot sysroot/$(ARCH)
@@ -199,7 +209,7 @@ run-user: nolibc-test $(Q)$(REPORT) $(CURDIR)/run.out
initramfs.cpio: kernel nolibc-test - $(QUIET_GEN)echo 'file /init nolibc-test 755 0 0' | $(srctree)/usr/gen_init_cpio - > initramfs.cpio + $(QUIET_GEN)echo 'file /init nolibc-test 755 0 0' | $(objtree)/usr/gen_init_cpio - > initramfs.cpio
initramfs: nolibc-test $(QUIET_MKDIR)mkdir -p initramfs @@ -217,12 +227,12 @@ kernel-standalone: initramfs
# run the tests after building the kernel run: kernel initramfs.cpio - $(Q)qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(srctree)/$(IMAGE)" -initrd initramfs.cpio -serial stdio $(QEMU_ARGS) > "$(CURDIR)/run.out" + $(Q)qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(IMAGE)" -initrd initramfs.cpio -serial stdio $(QEMU_ARGS) > "$(CURDIR)/run.out" $(Q)$(REPORT) $(CURDIR)/run.out
# re-run the tests from an existing kernel rerun: - $(Q)qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(srctree)/$(IMAGE)" -initrd initramfs.cpio -serial stdio $(QEMU_ARGS) > "$(CURDIR)/run.out" + $(Q)qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(IMAGE)" -initrd initramfs.cpio -serial stdio $(QEMU_ARGS) > "$(CURDIR)/run.out" $(Q)$(REPORT) $(CURDIR)/run.out
# report with existing test log
On Tue, Oct 10, 2023 at 02:33:59PM +0200, Thomas Weißschuh wrote:
Out of tree builds are much more convenient when building for multiple architectures or configurations in parallel.
Only absolute O= parameters are supported as Makefile.include will always resolve relative paths in relation to $(srctree) instead of the current directory.
Add a call to "make outputmakefile" to verify that the sourcetree is clean.
At first this worried me, I thought you meant clean in the git meaning, but it's clean as in "make clean" from what I'm seeing. Yeah that sounds reasonable.
This is based on Zhangjins out-of-tree patch. It extends that work for get_init_cpio support and also drops relative O= specifications explicitly.
Yeah I remember these discussions about these shortcomings, that's pretty reasonable.
Link: https://lore.kernel.org/lkml/06d96bd81fe812a9718098a383678ad3beba98b1.169121... Signed-off-by: Thomas Weißschuh linux@weissschuh.net
(...)
I think you should add a Suggested-by at least since Zhangjin attempted that work quite a few times already and allowed to make progress in that direction (maybe even co-developed, I'm not sure).
Acked-by: Willy Tarreau w@1wt.eu Willy
Oct 22, 2023 11:31:32 Willy Tarreau w@1wt.eu:
On Tue, Oct 10, 2023 at 02:33:59PM +0200, Thomas Weißschuh wrote:
Out of tree builds are much more convenient when building for multiple architectures or configurations in parallel.
Only absolute O= parameters are supported as Makefile.include will always resolve relative paths in relation to $(srctree) instead of the current directory.
Add a call to "make outputmakefile" to verify that the sourcetree is clean.
At first this worried me, I thought you meant clean in the git meaning, but it's clean as in "make clean" from what I'm seeing. Yeah that sounds reasonable.
This is based on Zhangjins out-of-tree patch. It extends that work for get_init_cpio support and also drops relative O= specifications explicitly.
Yeah I remember these discussions about these shortcomings, that's pretty reasonable.
Link: https://lore.kernel.org/lkml/06d96bd81fe812a9718098a383678ad3beba98b1.169121... Signed-off-by: Thomas Weißschuh linux@weissschuh.net
(...)
I think you should add a Suggested-by at least since Zhangjin attempted that work quite a few times already and allowed to make progress in that direction (maybe even co-developed, I'm not sure).
Indeed. For a proper Co-developed-by I also need a Signed-off-by by Zhangjin.
Zhangjin, are you fine with giving me one for this patch?
Acked-by: Willy Tarreau w@1wt.eu
Thanks!
Hi, Thomas
Oct 22, 2023 11:31:32 Willy Tarreau w@1wt.eu:
(...)
I think you should add a Suggested-by at least since Zhangjin attempted that work quite a few times already and allowed to make progress in that direction (maybe even co-developed, I'm not sure).
Indeed. For a proper Co-developed-by I also need a Signed-off-by by Zhangjin.
Zhangjin, are you fine with giving me one for this patch?
It is ok for me, thanks very much to make it really works!
BR, Zhangjin Wu
Acked-by: Willy Tarreau w@1wt.eu
Thanks!
This new target generates a .config if none exists yet.
Also drop the defconfig target with its hidden call to 'mrproper' which is fairly invasive. If users want to overwrite their kernel existing kernel configuration they can do so easily from the toplevel directory.
Signed-off-by: Thomas Weißschuh linux@weissschuh.net --- tools/testing/selftests/nolibc/Makefile | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 21e3f7da2ecf..5a3623680f1a 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -173,7 +173,7 @@ all: run
sysroot: sysroot/$(ARCH)/include
-sysroot/$(ARCH)/include: +sysroot/$(ARCH)/include: $(objtree)/.config $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot $(QUIET_MKDIR)mkdir -p sysroot $(Q)$(MAKE) -C $(srctree) outputmakefile @@ -216,13 +216,13 @@ initramfs: nolibc-test $(call QUIET_INSTALL, initramfs/init) $(Q)cp nolibc-test initramfs/init
-defconfig: - $(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) mrproper $(DEFCONFIG) prepare +$(objtree)/.config: + $(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) $(DEFCONFIG)
-kernel: +kernel: $(objtree)/.config $(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) $(IMAGE_NAME)
-kernel-standalone: initramfs +kernel-standalone: $(objtree)/.config initramfs $(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) $(IMAGE_NAME) CONFIG_INITRAMFS_SOURCE=$(CURDIR)/initramfs
# run the tests after building the kernel
On Tue, Oct 10, 2023 at 02:34:00PM +0200, Thomas Weißschuh wrote:
This new target generates a .config if none exists yet.
Also drop the defconfig target with its hidden call to 'mrproper' which is fairly invasive. If users want to overwrite their kernel existing kernel configuration they can do so easily from the toplevel directory.
Hmmm I'm not sure about that one, I pretty much remember seeing failing arm64 builds when mrproper and prepare were missing.
I would argue that someone starting "make defconfig" does expect the config to be dropped, hence mrproper to be called as well.
What specific issue did you face with it ? Maybe we can restrict it to only a few cases ?
Willy
Oct 22, 2023 11:37:05 Willy Tarreau w@1wt.eu:
On Tue, Oct 10, 2023 at 02:34:00PM +0200, Thomas Weißschuh wrote:
This new target generates a .config if none exists yet.
Also drop the defconfig target with its hidden call to 'mrproper' which is fairly invasive. If users want to overwrite their kernel existing kernel configuration they can do so easily from the toplevel directory.
Hmmm I'm not sure about that one, I pretty much remember seeing failing arm64 builds when mrproper and prepare were missing.
I would argue that someone starting "make defconfig" does expect the config to be dropped, hence mrproper to be called as well.
What specific issue did you face with it ? Maybe we can restrict it to only a few cases ?
It was mostly a quality improvement for my testscript, where the config was generated automatically.
And then I dropped the combined defconfig target because it seemed unnecessary.
Let's drop this patch.
Thomas
linux-kselftest-mirror@lists.linaro.org
-
Thomas Weißschuh -
Thomas Weißschuh -
Willy Tarreau -
Zhangjin Wu