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 C15E7D811CC for ; Fri, 26 Jan 2024 14:00:07 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=1rFnYNdFNHle6W+fjLwXuTKIS/npzY3LtuHuginewBs=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20140610; t=1706277606; v=1; b=QZlIkLbd2N9eLMXkairb4Uude5d/3yMGH+M6GRoxKaaiBFAE7o+q8gB5+1Ug9IUTuqb6Dtn3 KLyQ0eO+hxqjvJO2Nt2xMCPop5pIiv/DXfQZTx6Lp6HvDBf+GSMowRRRyewUknPPLUQhSf1zEb1 CGcc1kN6ae2OLcbUJzNr7u8Q= X-Received: by 127.0.0.2 with SMTP id arjHYY7687511xYG8gz1Paf9; Fri, 26 Jan 2024 06:00:06 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.16563.1706277605697943056 for ; Fri, 26 Jan 2024 06:00:05 -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-440-EjoAZuuRPm607GuJtlCUZg-1; Fri, 26 Jan 2024 09:00:01 -0500 X-MC-Unique: EjoAZuuRPm607GuJtlCUZg-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 1554A859B82; Fri, 26 Jan 2024 14:00:01 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.194.174]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DA59BC15E61; Fri, 26 Jan 2024 14:00:00 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id EA0311800605; Fri, 26 Jan 2024 14:59:59 +0100 (CET) Date: Fri, 26 Jan 2024 14:59:59 +0100 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, Jiewen Yao , Ard Biesheuvel , Michael Roth , Erdem Aktas , Min Xu , Tom Lendacky , Oliver Steffen Subject: Re: [edk2-devel] [PATCH 02/11] OvmfPkg: add ShellLibs.dsc.inc Message-ID: References: <20240124163802.2160303-1-kraxel@redhat.com> <20240124163802.2160303-3-kraxel@redhat.com> <53e77c3c-86ad-b3fb-9474-0a4a7cdcb80f@redhat.com> MIME-Version: 1.0 In-Reply-To: <53e77c3c-86ad-b3fb-9474-0a4a7cdcb80f@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 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,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: b2CZomZlLqeBUFNNUabBrtjWx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=QZlIkLbd; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) Hi, > My preferred style is observed for example in: > > - NetworkPkg/NetworkLibs.dsc.inc > - RedfishPkg/RedfishLibs.dsc.inc > > Alas, it is not observed in: > > - MdePkg/MdeLibs.dsc.inc > - OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc > > At least, from the last two, OvmfTpmLibs.dsc.inc has an excuse: it > provides library class resolutions for different module types. Which is why I did it that way for TPM. A single include file is enough instead of having multiple include files for multiple module types. The OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc is placed in a location where this works without problems, and I've placed the new shell include at the same location. I also have a WIP patch series (need to undust and rebase it ...) doing the same for the crypto stuff, and that has the same problem the TPM include has: We have different configurations for PEI (stripped down config, with only the hash functions for measurements) and DXE (full TLS support). And it is a single file with multiple sections too ... tl;dr: I prefer the with-sections style. > (2) This change makes the ShellCEntryLib resolution dependent on > BUILD_SHELL, which is a functional change, and it is not justified, > AFAICT. > (2.1) "Bare bones" is for example > "MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.inf". > [ ... ] > (2.2) shell app is for example > "OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf". > [ ... ] Thanks for all this background info, much appreciated. > Our BUILD_SHELL macro controls whether we build the shell itself, but > that is independent of whether we build applications that require the > shell to launch them. Making the ShellCEntryLib class resolution > dependent on BUILD_SHELL would only be valid if we also built all the > shell applications dependent on the BUILD_SHELL macro -- which is not > the case. 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 (and also move it into Shell*.inc) ? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114613): https://edk2.groups.io/g/devel/message/114613 Mute This Topic: https://groups.io/mt/103935344/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-