All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: thuth@redhat.com, kvm@vger.kernel.org, zixuanwang@google.com,
	kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com,
	varad.gautam@suse.com
Subject: Re: [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi
Date: Thu, 10 Feb 2022 17:25:46 +0000	[thread overview]
Message-ID: <YgVKmjBnAjITQcm+@google.com> (raw)
In-Reply-To: <20220210150943.1280146-1-alexandru.elisei@arm.com>

On Thu, Feb 10, 2022, Alexandru Elisei wrote:
> I renamed --target-efi to --efi-payload in the last patch because I felt it
> looked rather confusing to do ./configure --target=qemu --target-efi when
> configuring the tests. If the rename is not acceptable, I can think of a
> few other options:

I find --target-efi to be odd irrespective of this new conflict.  A simple --efi
seems like it would be sufficient.

> 1. Rename --target to --vmm. That was actually the original name for the
> option, but I changed it because I thought --target was more generic and
> that --target=efi would be the way going forward to compile kvm-unit-tests
> to run as an EFI payload. I realize now that separating the VMM from
> compiling kvm-unit-tests to run as an EFI payload is better, as there can
> be multiple VMMs that can run UEFI in a VM. Not many people use kvmtool as
> a test runner, so I think the impact on users should be minimal.

Again irrespective of --target-efi, I think --target for the VMM is a potentially
confusing name.  Target Triplet[*] and --target have specific meaning for the
compiler, usurping that for something similar but slightly different is odd.

But why is the VMM specified at ./configure time?  Why can't it be an option to
run_tests.sh?  E.g. --target-efi in configure makes sense because it currently
requires different compilation options, but even that I hope we can someday change
so that x86-64 always builds EFI-friendly tests.  I really don't want to get to a
point where tests themselves have to be recompiled to run under different VMMs.

[*] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: pbonzini@redhat.com, thuth@redhat.com, drjones@redhat.com,
	varad.gautam@suse.com, zixuanwang@google.com,
	kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi
Date: Thu, 10 Feb 2022 17:25:46 +0000	[thread overview]
Message-ID: <YgVKmjBnAjITQcm+@google.com> (raw)
In-Reply-To: <20220210150943.1280146-1-alexandru.elisei@arm.com>

On Thu, Feb 10, 2022, Alexandru Elisei wrote:
> I renamed --target-efi to --efi-payload in the last patch because I felt it
> looked rather confusing to do ./configure --target=qemu --target-efi when
> configuring the tests. If the rename is not acceptable, I can think of a
> few other options:

I find --target-efi to be odd irrespective of this new conflict.  A simple --efi
seems like it would be sufficient.

> 1. Rename --target to --vmm. That was actually the original name for the
> option, but I changed it because I thought --target was more generic and
> that --target=efi would be the way going forward to compile kvm-unit-tests
> to run as an EFI payload. I realize now that separating the VMM from
> compiling kvm-unit-tests to run as an EFI payload is better, as there can
> be multiple VMMs that can run UEFI in a VM. Not many people use kvmtool as
> a test runner, so I think the impact on users should be minimal.

Again irrespective of --target-efi, I think --target for the VMM is a potentially
confusing name.  Target Triplet[*] and --target have specific meaning for the
compiler, usurping that for something similar but slightly different is odd.

But why is the VMM specified at ./configure time?  Why can't it be an option to
run_tests.sh?  E.g. --target-efi in configure makes sense because it currently
requires different compilation options, but even that I hope we can someday change
so that x86-64 always builds EFI-friendly tests.  I really don't want to get to a
point where tests themselves have to be recompiled to run under different VMMs.

[*] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html

  parent reply	other threads:[~2022-02-10 17:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 15:09 [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi Alexandru Elisei
2022-02-10 15:09 ` Alexandru Elisei
2022-02-10 15:09 ` [kvm-unit-tests PATCH 1/4] configure: Fix whitespaces for the --gen-se-header help text Alexandru Elisei
2022-02-10 15:09   ` Alexandru Elisei
2022-02-10 15:09 ` [kvm-unit-tests PATCH 2/4] configure: Restrict --target-efi to x86_64 Alexandru Elisei
2022-02-10 15:09   ` Alexandru Elisei
2022-02-10 15:09 ` [kvm-unit-tests PATCH 3/4] configure: Make the --target option available to all architectures Alexandru Elisei
2022-02-10 15:09   ` Alexandru Elisei
2022-02-10 15:09 ` [kvm-unit-tests PATCH RFC 4/4] Rename --target-efi to --efi-payload Alexandru Elisei
2022-02-10 15:09   ` Alexandru Elisei
2022-02-10 17:25 ` Sean Christopherson [this message]
2022-02-10 17:25   ` [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi Sean Christopherson
2022-02-10 17:45   ` Alexandru Elisei
2022-02-10 17:45     ` Alexandru Elisei
2022-02-10 17:48     ` Alexandru Elisei
2022-02-10 17:48       ` Alexandru Elisei
2022-02-10 19:30     ` Zixuan Wang
2022-02-10 19:30       ` Zixuan Wang
2022-02-10 19:36       ` Sean Christopherson
2022-02-10 19:36         ` Sean Christopherson
2022-02-10 19:48         ` Zixuan Wang
2022-02-10 19:48           ` Zixuan Wang
2022-02-11  7:47           ` Andrew Jones
2022-02-11  7:47             ` Andrew Jones
2022-02-11  8:13           ` Thomas Huth
2022-02-11  8:13             ` Thomas Huth
2022-02-11 16:19             ` Sean Christopherson
2022-02-11 16:19               ` Sean Christopherson
2022-02-17 12:14               ` Alexandru Elisei
2022-02-17 12:14                 ` Alexandru Elisei

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=YgVKmjBnAjITQcm+@google.com \
    --to=seanjc@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=pbonzini@redhat.com \
    --cc=thuth@redhat.com \
    --cc=varad.gautam@suse.com \
    --cc=zixuanwang@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.