From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by mx.groups.io with SMTP id smtpd.web10.10262.1584022809880575811 for ; Thu, 12 Mar 2020 07:20:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=bV+YpHlp; spf=pass (domain: nuviainc.com, ip: 209.85.221.65, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f65.google.com with SMTP id l18so7671657wru.11 for ; Thu, 12 Mar 2020 07:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DVena2K5vKAIYHI7nIQRzxyk0STMOkokX76J7+O3gcI=; b=bV+YpHlpJwh6Ub8pwkpTNjkyL1mWEdoekIl31jP7PExGwUi1geZnBGE2kSqftt8CSg XOFGAsYtN72IoNaQBHHgh1/1tRkkE8A2vC7Qs4gqtstC1vdDSKYWkuFKEzxwEY3MzE/p sGmFkY9c8ItrHGkbCEQZoLUzfg2H3G6/+fO1aMZn0yBeBgsieZnlYSSknbHAKh80cK1J LTD8qpsuzqr+4xIKgkaLiszKYhkHfTifh7m1zBqWoHllULTm3xstT1J9+VaMX9OWB7n2 UJTA0At3zb1nwQYc8vwrHu/P+CDn0P1yAypbZQIfEjCCRFecWqPKpD2bgMsecrPXG1+8 +5Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DVena2K5vKAIYHI7nIQRzxyk0STMOkokX76J7+O3gcI=; b=CoXlODU8i9jhnG3+polFPCiYd9yfjE45QtfQOlp48q4EfQLtIi4rIsFwnMvTTOimN1 1E/OwFZhtSGdqYoLN8fV/yAsu5A2ev1Z13F0WEcPEIKUOng9bUNEi1QfDIQ4h+EwY7nM VO1tSNPDmGMohTKsm3xiwc1g6Q7pBTFiVbbsbwWwXI8JuMphPvC9dzSsWOqgDso/DsxU Cp52zraWVBB0rbDQqFAK7tJNf1xtLsOP6vcCpSB0g8uzRpJ/GS3QY7xbNUBPjOm+SEkU 59byrJqyEVaQZ6Y8/NUa58Wjd63J8ee02EZKUCQKrmKYUwPQF7VHGDHtl6y8RP5fjIbv Vqbg== X-Gm-Message-State: ANhLgQ0KrdOBjev2sJcEXkEGtHQEcSYTzItY8zSmHqJfm0qBSiTLA8T8 lpIwJfu9Uomn/mh9P24oUhBwMQ== X-Google-Smtp-Source: ADFU+vvfX3HrzTKPBAa8VAu85GLv85tPOLrPK1eazTDN0hRfux7ApAkoYUCqq87LjapGgqwKAe47Ow== X-Received: by 2002:adf:ed8a:: with SMTP id c10mr11024752wro.423.1584022808441; Thu, 12 Mar 2020 07:20:08 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id l17sm14192304wmg.23.2020.03.12.07.20.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2020 07:20:07 -0700 (PDT) Date: Thu, 12 Mar 2020 14:20:06 +0000 From: "Leif Lindholm" To: Laszlo Ersek Cc: devel@edk2.groups.io, Ard Biesheuvel , Jordan Justen , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Subject: Re: [edk2-devel] [PATCH 3/5] OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE Message-ID: <20200312142006.GG23627@bivouac.eciton.net> References: <20200310222739.26717-1-lersek@redhat.com> <20200310222739.26717-4-lersek@redhat.com> <20200311154449.GR23627@bivouac.eciton.net> <4a412430-d0a3-6310-0d2d-de2da6c00639@redhat.com> <20200311162026.GX23627@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 11, 2020 at 17:41:04 +0100, Laszlo Ersek wrote: > >> A recent example of this was my request for NetworkPkg to expose its > >> include snippets header-less, for DSC files. Please see the "!include > >> NetworkPkg/..." directives in the OVMF DSC files; those are also by > >> design header-less: > >> > >> NetworkPkg/NetworkComponents.dsc.inc > >> NetworkPkg/NetworkDefines.dsc.inc > >> NetworkPkg/NetworkLibs.dsc.inc > >> NetworkPkg/NetworkPcds.dsc.inc > > > > ...could OvmfPkg use a similar naming scheme to this? > > > > That would also remove the drawback of not having the section name as > > part of the hunk header, as you'd have it anyway immediately above as > > part of the file name? > > There are three FDF include files: > > (1) DecomprScratchEnd.fdf.inc (included under [FV.FVMAIN_COMPACT], per > commit 9beac0d847bf9): > > ## @file > # This FDF include file computes the end of the scratch buffer used in > # DecompressMemFvs() [OvmfPkg/Sec/SecMain.c]. It is based on the decompressed > # (ie. original) size of the LZMA-compressed section of the one FFS file in > # the FVMAIN_COMPACT firmware volume. > # > # Copyright (C) 2015, Red Hat, Inc. > # > # SPDX-License-Identifier: BSD-2-Clause-Patent > ## > > This include file contains DEFINE and SET statements (for setting macros > and PCDs, accordingly). I don't think either a "Defines" or "Pcds" > suffix would apply. Would FvmainCompactScratchEnd.fdf.inc be an option? > (2) OvmfPkg.fdf.inc (included under [Defines]): > > ## @file > # FDF include file that defines the main macros and sets the dependent PCDs. > # > # Copyright (C) 2014, Red Hat, Inc. > # Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> # > # SPDX-License-Identifier: BSD-2-Clause-Patent > # > ## > > Same situation (both DEFINE and SET statements). However, it *needs* to be included inside the [Defines] section, so there is no need to get philosofical: It's OvmfPkgDefines.fdf.inc (or OvmfDefines.fdf.inc). This aligns 100% with the NetworkPkg example. > (3) VarStore.fdf.inc (included under [FD.OVMF] and [FD.OVMF_VARS]): > > ## @file > # FDF include file with Layout Regions that define an empty variable store. > # > # Copyright (C) 2014, Red Hat, Inc. > # Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> # > # SPDX-License-Identifier: BSD-2-Clause-Patent > # > ## > > I guess we could rename this to "VarStoreLayoutRegions.fdf.inc" -- but > would that really help? OK, so this one is different because it can be included in more than one location. Also, it's not the sort of thing you need to touch if you're not already in the sixth circle of hell. > I'm not against introducing helpful name suffixes, I just can't find > anything that really fits and significantly improves upon the current > names. I vaguely remember racking my brain when I was introducing these > files, for better names, and this is what I had come up with. :) Sure, this all predates the NetworkPkg fragments (or really any fragments). It would just be nice to be able to start aligning this across packages. Splitting up the ARM fragment files is also totally on the table here. / Leif