public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	kernel@collabora.com,  kvm@vger.kernel.org,
	linux-kselftest@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Marc Zyngier <maz@kernel.org>,
	 Oliver Upton <oliver.upton@linux.dev>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	 Janosch Frank <frankja@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	 Anup Patel <anup@brainfault.org>
Subject: Re: [PATCH v2] selftests: kvm: fix mkdir error when building for unsupported arch
Date: Mon, 19 Aug 2024 09:33:17 -0700	[thread overview]
Message-ID: <ZsNzzajqBkmuu5Xm@google.com> (raw)
In-Reply-To: <20240819093030.2864163-1-usama.anjum@collabora.com>

+KVM arch maintainers

On Mon, Aug 19, 2024, Muhammad Usama Anjum wrote:
> The tests are built on per architecture basis. When unsupported
> architecture is specified, it has no tests and TEST_GEN_PROGS is empty.
> The lib.mk has support for not building anything for such case. But KVM
> makefile doesn't handle such case correctly. It doesn't check if
> TEST_GEN_PROGS is empty or not and try to create directory by mkdir.
> Hence mkdir generates the error.
> 
> mkdir: missing operand
> Try 'mkdir --help' for more information.
> 
> This can be easily fixed by checking if TEST_GEN_PROGS isn't empty
> before calling mkdir.
> 
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> Changes since v1:
> - Instead of ignoring error, check TEST_GEN_PROGS's validity first
> ---
>  tools/testing/selftests/kvm/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index 48d32c5aa3eb7..9f8ed82ff1d65 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -317,7 +317,9 @@ $(LIBKVM_S_OBJ): $(OUTPUT)/%.o: %.S $(GEN_HDRS)
>  $(LIBKVM_STRING_OBJ): $(OUTPUT)/%.o: %.c
>  	$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -ffreestanding $< -o $@
>  
> +ifneq ($(strip $(TEST_GEN_PROGS)),)
>  $(shell mkdir -p $(sort $(dir $(TEST_GEN_PROGS))))
> +endif

This just suppresses an error, it doesn't fix the underlying problem.  E.g. there
are other weird side effects, such as an above mkdir creating the $(ARCH) directory
even though it shouldn't exist in the end.

It's also very opaque, e.g. without a comment or the context of the changelog,
I'd have no idea what purpose the above serves.

Rather than bury the effective "is this arch supported" check in the middle of
the Makefile, what if we wrap the "real" makefile and include it only for
supported architectures, and provide dummy targets for everything else?

E.g.

---
# SPDX-License-Identifier: GPL-2.0-only
top_srcdir = ../../../..
include $(top_srcdir)/scripts/subarch.include
ARCH            ?= $(SUBARCH)

ifeq ($(ARCH),$(filter $(ARCH),arm64 s390 riscv x86 x86_64))
ifeq ($(ARCH),x86)
        ARCH_DIR := x86_64
else ifeq ($(ARCH),arm64)
        ARCH_DIR := aarch64
else ifeq ($(ARCH),s390)
        ARCH_DIR := s390x
else
        ARCH_DIR := $(ARCH)
endif

include Makefile.kvm
else
all:
clean:
endif
---

And other KVM maintainers, the big question is: if we do the above, would now be
a decent time to bite the bullet and switch to the kernel's canonical arch paths,
i.e. arm64, s390, and x86?  I feel like if we're ever going to get away from
using aarch64, x86_64, and s390x, this is as about a good of an opportunity as
we're going to get.

The annoying x86_64=>x86 alias still needs to be handled to avoid breaking explicit
ARCH=x86_64 builds (which apparently are allowed, *sigh*), but we can ditch ARCH_DIR
and the KVM selftests dirs match tools' include paths.

---
# SPDX-License-Identifier: GPL-2.0-only
top_srcdir = ../../../..
include $(top_srcdir)/scripts/subarch.include
ARCH            ?= $(SUBARCH)

ifeq ($(ARCH),$(filter $(ARCH),arm64 s390 riscv x86 x86_64))
# Top-level selftests allows ARCH=x86_64 :-(
ifeq ($(ARCH),x86_64)
	ARCH := x86
endif
include Makefile.kvm
else
all:
clean:
endif
---

If no one objects or has a better idea, I'll post a series to do the above.

  parent reply	other threads:[~2024-08-19 16:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19  9:30 [PATCH v2] selftests: kvm: fix mkdir error when building for unsupported arch Muhammad Usama Anjum
2024-08-19 10:01 ` Shuah Khan
2024-08-19 16:33 ` Sean Christopherson [this message]
2024-08-19 22:15   ` Oliver Upton
2024-08-20  6:40     ` Marc Zyngier
2024-08-20  7:26   ` Muhammad Usama Anjum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZsNzzajqBkmuu5Xm@google.com \
    --to=seanjc@google.com \
    --cc=anup@brainfault.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kernel@collabora.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --cc=usama.anjum@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox