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
next prev parent 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