On 2023-09-17 05:22:19+0200, Willy Tarreau wrote: > On Sat, Sep 16, 2023 at 09:13:26AM +0200, Thomas Weißschuh wrote: > > Currently the nolibc testsuite embeds the test executable into a kernel > > image with CONFIG_INITRAMFS_SOURCE. > > This forces a full kernel relink everytime the test executable is > > updated. > > > > This relinking step dominates the test cycle. > > It is slower than building and running the test in qemu together. > > > > With a bit of Makefile-shuffling the relinking can be avoided. > > That's pretty nice as indeed it still takes a while to relink it into > the kernel. I agree that for running nolibc-test in qemu we don't need > a unified image. However I've seldom used it on real hardware and I > find it significantly more convenient to use as a single image in this > case. Maybe we should just rename targets so that everything qemu-related > just uses two distinct images while a "unified-image" (or anything else) > still assembles the image into the kernel (BTW the help on the "kernel" > target still mentions initramfs). Sounds good, "unified-image" is a bit close to "unified kernel image" (UKI) which is similar but different. What about kernel-standalone? > Note that we don't need to modify anything in the build system to create > an initrd, I usually make them by hand using "cpio -o -H newc", we don't > need anything else here. I'd like to keep the build self-contained. But actually the kernel build will always build a minimal initramfs if CONFIG_BLK_DEV_INITRD is set. This config is needed for the nolibc testsuite in any case. The fact that the initrd is always build means that usr/gen_init_cpio is also always build. So we can add "kernel" as a prerequisite to "initramfs.cpio" and everything should work out without any buildsystem modifications. > Regarding rerun, I'd rather keep it for the sole reason that I've used > it to check for randomly failing errors (typically the timing-based > ones). It's convenient to run the same image 100 times if needed. I'm > not strongly attached to it, but if "make run" is slower, then we can > keep it. However if you really want to drop it, it also needs to be > dropped from the help message ;-) Fine for me, let's keep it :-)
