From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web12.9926.1584051607456732302 for ; Thu, 12 Mar 2020 15:20:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OWFmCORO; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584051606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aMlNa9ucayzMmLAygl9hRxMKtiaefh/gr3Lj99UMi5Y=; b=OWFmCOROQSbd9Oj9hj6+LXKAPOzxU0PTlR8cHBzVZBL5JBSs0xTaKMw7f2BchuKSbaIKx6 1LkxZ9Q8gEay93LotXq2+YGI70oeAq0l/4sp6j/T2AXepsmxxWoFG+/4avXaLGAP3K5y7M ilb+LEicgTK4lW/paMV6rv/jNhdT7yw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-EsE4_SYaPFqfL2Kyx17tFw-1; Thu, 12 Mar 2020 18:20:03 -0400 X-MC-Unique: EsE4_SYaPFqfL2Kyx17tFw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E86F1189D6C4; Thu, 12 Mar 2020 22:20:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-74.ams2.redhat.com [10.36.117.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 722FC19C6A; Thu, 12 Mar 2020 22:20:00 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 3/5] OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE To: Leif Lindholm Cc: devel@edk2.groups.io, Ard Biesheuvel , Jordan Justen , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= 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> <20200312142006.GG23627@bivouac.eciton.net> From: "Laszlo Ersek" Message-ID: <1b2d9e38-ac25-c381-4c86-3cff46af297b@redhat.com> Date: Thu, 12 Mar 2020 23:19:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200312142006.GG23627@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/12/20 15:20, Leif Lindholm wrote: > 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 > I'll send a patch for (1) and (2). Thanks Laszlo