From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 1FC367803DA for ; Mon, 29 Jan 2024 12:40:39 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=PgFMZAjuPMlz3099jeADnD7Q10hKuA1O7gJ96jLKtgQ=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1706532038; v=1; b=DceE7p9mT94zYJxg3Ib/x+oews7JfYSN0/TbNT6/29LndcC9aibj9f70z7qlisclU0eKsRuD 5L8ZYA1Y12wfLKw2OoPP91PnKzisAoTUdSAI/U46BXxMWK/TUq1wcp6r7ncCFEXNXvWZLLw7Llr eQwA7nY9PBCakacz6OVpF3kw= X-Received: by 127.0.0.2 with SMTP id bB2uYY7687511xIWhbAvApyu; Mon, 29 Jan 2024 04:40:38 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.13762.1706532037983663212 for ; Mon, 29 Jan 2024 04:40:38 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-247-hTiYzyNMOWmgqQkZNMr1pQ-1; Mon, 29 Jan 2024 07:40:33 -0500 X-MC-Unique: hTiYzyNMOWmgqQkZNMr1pQ-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A3B88101A526; Mon, 29 Jan 2024 12:40:32 +0000 (UTC) X-Received: from [10.39.193.158] (unknown [10.39.193.158]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4B41840C9444; Mon, 29 Jan 2024 12:40:31 +0000 (UTC) Message-ID: <8c832ba8-93fe-acc5-7990-649ff19a9fa1@redhat.com> Date: Mon, 29 Jan 2024 13:40:30 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 02/11] OvmfPkg: add ShellLibs.dsc.inc To: devel@edk2.groups.io, kraxel@redhat.com Cc: Jiewen Yao , Ard Biesheuvel , Michael Roth , Erdem Aktas , Min Xu , Tom Lendacky , Oliver Steffen References: <20240124163802.2160303-1-kraxel@redhat.com> <20240124163802.2160303-3-kraxel@redhat.com> <53e77c3c-86ad-b3fb-9474-0a4a7cdcb80f@redhat.com> <0e3aed3d-f1a5-e400-01bf-26c87445089f@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: OjHq4KTdnzpTSXnncZLqNHDux7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=DceE7p9m; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io 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.ef= i. >> >>> (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. >=20 > We can certainly try to find a better name. > How about Applications*.inc? >=20 > 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 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-