public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, kraxel@redhat.com
Cc: Jiewen Yao <jiewen.yao@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Michael Roth <michael.roth@amd.com>,
	Erdem Aktas <erdemaktas@google.com>, Min Xu <min.m.xu@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Oliver Steffen <osteffen@redhat.com>
Subject: Re: [edk2-devel] [PATCH 02/11] OvmfPkg: add ShellLibs.dsc.inc
Date: Mon, 29 Jan 2024 13:40:30 +0100	[thread overview]
Message-ID: <8c832ba8-93fe-acc5-7990-649ff19a9fa1@redhat.com> (raw)
In-Reply-To: <p7iwe3tqqoj7ln3jqqlfsgqvm42cuftr2qxasdknbwqfj5vudq@in6sswalo4vl>

On 1/29/24 13:25, Gerd Hoffmann wrote:
>>> Given that EnrollDefaultKeys depends on the shell to launch
>>> I'm wondering whenever we should just change that and make the
>>> EnrollDefaultKeys build depend on BUILD_SHELL
>>
>> This certainly sounds justified. It's hard to imagine a use case where
>> someone wanted an EnrollDefaultKeys.efi binary, but not a fresh shell.efi.
>>
>>> (and also move it into Shell*.inc) ?
>>
>> Seems to make sense, technically speaking; it's again the naming that
>> annoys me a bit. :( It's a utility that's supposed to be run from under
>> the shell, but not related to the shell itself. Hmm. :/
>>
>> I guess we can live with it.
> 
> We can certainly try to find a better name.
> How about Applications*.inc?
> 
> In that case it'll probably make sense to also move UiApp.

Moving UiApp seems counter-productive. UiApp needs to be included in the
firmware image. Its FILE_GUID (from the INF file) is referenced by
PcdBootManagerMenuFile. The same does not apply to
EnrollDefaultKeys.efi, which we don't build into the firmware image.

It's like UiApp and the shell might go in one kind of include file
(set), and EnrollDefaultKeys should be separate.

But... what's the original purpose here? Including the shell in a bunch
of DSC and FDF files is a chore, because the DSC snippet is large (and
so it can easily become inconsistent between DSCs). That's what we want
to solve, right?

Meaning we could leave EnrollDefaultKeys alone, for now (regardless of
whether we decide to make it dependent on BUILD_SHELL as well,
separately). It means means we wouldn't extract / centralize as much
code as technically possible perhaps, but at least we don't increase
semantic confusion.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114699): https://edk2.groups.io/g/devel/message/114699
Mute This Topic: https://groups.io/mt/103935344/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-01-29 12:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24 16:37 [edk2-devel] [PATCH 00/11] OvmfPkg: tweak shell builds Gerd Hoffmann
2024-01-24 16:37 ` [edk2-devel] [PATCH 01/11] OvmfPkg: add ShellComponents.dsc.inc Gerd Hoffmann
2024-01-25 11:49   ` Laszlo Ersek
2024-01-24 16:37 ` [edk2-devel] [PATCH 02/11] OvmfPkg: add ShellLibs.dsc.inc Gerd Hoffmann
2024-01-25 13:14   ` Laszlo Ersek
2024-01-26 13:59     ` Gerd Hoffmann
2024-01-29 11:25       ` Laszlo Ersek
2024-01-29 12:25         ` Gerd Hoffmann
2024-01-29 12:40           ` Laszlo Ersek [this message]
2024-01-24 16:37 ` [edk2-devel] [PATCH 03/11] OvmfPkg: add ShellDxe.fdf.inc Gerd Hoffmann
2024-01-25 13:21   ` Laszlo Ersek
2024-01-24 16:37 ` [edk2-devel] [PATCH 04/11] OvmfPkg: Shell*.inc: allow building without network support Gerd Hoffmann
2024-01-25 13:53   ` Laszlo Ersek
2024-01-24 16:37 ` [edk2-devel] [PATCH 05/11] OvmfPkg: ShellDxe.fdf.inc: add VariablePolicyDynamicCommand to FV Gerd Hoffmann
2024-01-25 16:46   ` Laszlo Ersek
2024-01-24 16:37 ` [edk2-devel] [PATCH 06/11] OvmfPkg: switch OvmfPkgIa32 to new shell include files Gerd Hoffmann
2024-01-25 16:56   ` Laszlo Ersek
2024-01-24 16:37 ` [edk2-devel] [PATCH 07/11] OvmfPkg: switch OvmfPkgIa32X64 " Gerd Hoffmann
2024-01-25 16:57   ` Laszlo Ersek
2024-01-24 16:37 ` [edk2-devel] [PATCH 08/11] OvmfPkg: switch AmdSevX64 " Gerd Hoffmann
2024-01-25 17:02   ` Laszlo Ersek
2024-02-14 14:24     ` Gerd Hoffmann
2024-01-24 16:38 ` [edk2-devel] [PATCH 09/11] OvmfPkg: switch IntelTdxX64 " Gerd Hoffmann
2024-01-25 17:04   ` Laszlo Ersek
2024-01-24 16:38 ` [edk2-devel] [PATCH 10/11] OvmfPkg: switch MicrovmX64 " Gerd Hoffmann
2024-01-25 17:05   ` Laszlo Ersek
2024-01-24 16:38 ` [edk2-devel] [PATCH 11/11] OvmfPkg/CI: copy shell to virtual drive Gerd Hoffmann
2024-01-25 17:07   ` Laszlo Ersek
2024-01-25  3:09 ` [edk2-devel] [PATCH 00/11] OvmfPkg: tweak shell builds Yao, Jiewen

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-list 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=8c832ba8-93fe-acc5-7990-649ff19a9fa1@redhat.com \
    --to=devel@edk2.groups.io \
    /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