Hi, Willy
> On Sun, Jul 30, 2023 at 02:38:18PM +0800, Zhangjin Wu wrote:
> > with 'override', we are further able to use:
> >
> > $ make ARCH=powerpc
> > Makefile:29: *** ARCH=powerpc, XARCH=ppc. Stop.
> > $ make ARCH=ppc
> > Makefile:29: *** ARCH=powerpc, XARCH=ppc. Stop.
> > $ make ARCH=ppc64
> > Makefile:29: *** ARCH=powerpc, XARCH=ppc64. Stop.
> > $ make ARCH=ppc64le
> > Makefile:29: *** ARCH=powerpc, XARCH=ppc64le. Stop.
> >
> > So, with 'override', users will be able to directly use the famous ARCH, it is
> > able to accept powerpc, ppc, ppc64, ppc64le and users can simply ignore XARCH
> > and we are able to only use XARCH as an internal variable to temply save input
> > ARCH and then convert it to an internal ARCH.
>
> But it's extremely confusing as you can see above: the user passes
> one value and another one is found instead inside the makefile.
Yeah, there really is some deviation and confusion.
> Initially I said that I didn't want that we'd put incorrect values
> in ARCH so that it could be properly propagated through the various
> makefile layers and include files, and that led to XARCH.
>
I remember the good trick to set a default variant for ARCH.
> > Without 'override', we must carefully document its usage, it may be:
> >
> > # XARCH and ARCH mapping
> > #
> > # Usage:
> > # $ make ARCH=<kernel-supported-ARCH> XARCH=<nolibc-test-supported-variants> ...
> > #
> > # e.g. make ARCH=powerpc XARCH=[ppc|ppc64|ppc64le]
>
> Please let's do much simpler:
>
> # 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
> # a few specific values which are mapped like this:
> # XARCH ARCH config
> # ppc powerpc 32 bits
> # ppc64 powerpc 64 bits big endian
> # ppc64le powerpc 64 bits little endian
> #
> # It is recommended to only use XARCH, though it does not harm if
> # ARCH is already set. For simplicity, ARCH is sufficient for all
> # architectures where both are equal.
>
It is clearer enough, applied.
# 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
# a few specific values which are mapped like this:
#
# XARCH | ARCH | config
# -------------|-----------|-------------------------
# ppc | powerpc | 32 bits
# ppc64 | powerpc | 64 bits big endian
# ppc64le | powerpc | 64 bits little endian
#
# It is recommended to only use XARCH, though it does not harm if
# ARCH is already set. For simplicity, ARCH is sufficient for all
# architectures where both are equal.
# configure default variants for target kernel supported architectures
XARCH_powerpc = ppc
XARCH = $(or $(XARCH_$(ARCH)),$(ARCH))
# map from user input variants to their kernel supported architectures
ARCH_ppc = powerpc
ARCH_ppc64 = powerpc
ARCH_ppc64le = powerpc
ARCH := $(or $(ARCH_$(XARCH)),$(XARCH))
Any more discovery?
Note, ':=' above is required to fix up the 'recusive' warning when no
ARCH passed for the default x86.
> This way we'll even have the luxury of adding armv5, armv7 and thumb2
> if we want.
>
> > # XARCH is used to save user-input ARCH variant
> > # configure default variants for target kernel supported architectures
> >
> > For the help page, if we only use '\$$XARCH or \$$ARCH', it may mislead users:
> >
> > @echo " run-user runs the executable under QEMU (uses \$$ARCH or \\$XARCH, \$$TEST)"
> >
> > That's why I at last add the 'override' keyword to make sure even if users
> > wrongly and only use ARCH as the argument, it must not fail, or we forcely ask
> > user pass ARCH and XARCH together.
> >
> > @echo " run-user runs the executable under QEMU (uses \$$ARCH and \\$XARCH, \$$TEST)"
> >
> > Or we simply only and always ask users to use XARCH (as the first version does)
> > for nolibc-test and let ARCH as the default one from a previous build kernel:
> >
> > @echo " run-user runs the executable under QEMU (uses \$$XARCH, \$$TEST)"
>
> No, no, no, we don't use some defaults from a previous build. That makes
> problems much harder to debug and reproduce. However I'm fine with only
> indicating that QEMU uses XARCH if you want.
>
Ok, hope I have not misunderstood again ;-) so, here is the latest version I prepared:
help:
@echo "Supported targets under selftests/nolibc:"
@echo " all call the \"run\" target below"
@echo " help this help"
@echo " sysroot create the nolibc sysroot here (uses \$$ARCH)"
@echo " nolibc-test build the executable (uses \$$CC and \$$CROSS_COMPILE)"
@echo " libc-test build an executable using the compiler's default libc instead"
@echo " run-user runs the executable under QEMU (uses \$$XARCH, \$$TEST)"
@echo " initramfs prepare the initramfs with nolibc-test"
@echo " defconfig create a fresh new default config (uses \$$XARCH)"
@echo " kernel (re)build the kernel with the initramfs (uses \$$XARCH)"
@echo " run runs the kernel in QEMU after building it (uses \$$XARCH, \$$TEST)"
@echo " rerun runs a previously prebuilt kernel in QEMU (uses \$$XARCH, \$$TEST)"
@echo " clean clean the sysroot, initramfs, build and output files"
@echo ""
@echo "The output file is \"run.out\". Test ranges may be passed using \$$TEST."
@echo ""
@echo "Currently using the following variables:"
@echo " ARCH = $(ARCH)"
@echo " XARCH = $(XARCH)"
@echo " CROSS_COMPILE = $(CROSS_COMPILE)"
@echo " CC = $(CC)"
@echo " OUTPUT = $(OUTPUT)"
@echo " TEST = $(TEST)"
@echo " QEMU_ARCH = $(if $(QEMU_ARCH),$(QEMU_ARCH),UNKNOWN_ARCH) [determined from \$$XARCH]"
@echo " IMAGE_NAME = $(if $(IMAGE_NAME),$(IMAGE_NAME),UNKNOWN_ARCH) [determined from \$$XARCH]"
@echo ""
> > That means, the ugly 'override' does help us to save lots of teach work ;-)
>
> Precisely not. In my opinion you focus a lot on first use but not enough
> on troubleshooting. If someone wastes 20 minutes because they didn't want
> to take 20 seconds to read a help message, it's their problem. But if
> someones wastes one hour trying to debug a horribly inconsistent makefile
> that modifies their most critical variables along the execution, and they
> have to figure how to insert their stuff there to be accepted by the code,
> it's not respectful of their time and it becomes our problem.
>
It is reasonable, we did discuss this before, the critical area is small
but is there, so, it may really introduce risks in the future, let's
give up 'override' completely.
> > I'm ok with 'override' or not, welcome your confirm, which direction do you
> > prefer?
>
> The one with least complications and which doesn't override ARCH. Also
> please remember the example I provided where the test can be fired from
> the top dir where ARCH has a well-defined set of values. You found yourself
> inconvenient to have to change it between commands and that's why you were
> trying to add menuconfig here to work around this problem.
Best regards,
Zhangjin
>
> Thanks,
> Willy
