public inbox for kvmarm@lists.cs.columbia.edu
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Zixuan Wang <zxwang42@gmail.com>
Cc: thuth@redhat.com, kvm list <kvm@vger.kernel.org>,
	Zixuan Wang <zixuanwang@google.com>,
	kvmarm@lists.cs.columbia.edu, Paolo Bonzini <pbonzini@redhat.com>,
	Varad Gautam <varad.gautam@suse.com>
Subject: Re: [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi
Date: Thu, 10 Feb 2022 19:36:04 +0000	[thread overview]
Message-ID: <YgVpJDIfUVzVvFdx@google.com> (raw)
In-Reply-To: <CAEDJ5ZSR=rw_ALjBcLgeVz9H6TS67eWvZW2SvGTJV468WjgyKw@mail.gmail.com>

On Thu, Feb 10, 2022, Zixuan Wang wrote:
> On Thu, Feb 10, 2022 at 11:05 AM Alexandru Elisei
> <alexandru.elisei@arm.com> wrote:
> >
> > Hi,
> >
> > On Thu, Feb 10, 2022 at 05:25:46PM +0000, Sean Christopherson wrote:
> > > 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.
> >
> > Wouldn't that mean that --target-efi is equally confusing? Do you have
> > suggestions for other names?
> 
> How about --config-efi for configure, and CONFIG_EFI for source code?
> I thought about this name when I was developing the initial patch, and
> Varad also proposed similar names in his initial patch series [1]:
> --efi and CONFIG_EFI.

I don't mind CONFIG_EFI for the source, that provides a nice hint that it's a
configure option and is familiar for kernel developers.  But for the actually
option, why require more typing?  I really don't see any benefit of --config-efi
over --efi.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2022-02-10 19:36 UTC|newest]

Thread overview: 15+ 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 ` [kvm-unit-tests PATCH 1/4] configure: Fix whitespaces for the --gen-se-header help text 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 ` [kvm-unit-tests PATCH 3/4] configure: Make the --target option available to all architectures 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 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:48     ` Alexandru Elisei
2022-02-10 19:30     ` Zixuan Wang
2022-02-10 19:36       ` Sean Christopherson [this message]
2022-02-10 19:48         ` Zixuan Wang
2022-02-11  7:47           ` Andrew Jones
2022-02-11  8:13           ` Thomas Huth
2022-02-11 16:19             ` Sean Christopherson
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=YgVpJDIfUVzVvFdx@google.com \
    --to=seanjc@google.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 \
    --cc=zxwang42@gmail.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