From: "Carsey, Jaben" <jaben.carsey@intel.com>
To: "Feng, Bob C" <bob.c.feng@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Gao, Liming" <liming.gao@intel.com>
Subject: Re: [Patch] Document: Update DSC spec to remove EDK related contents
Date: Tue, 5 Mar 2019 15:24:24 +0000 [thread overview]
Message-ID: <CB6E33457884FA40993F35157061515CBCB9417C@FMSMSX103.amr.corp.intel.com> (raw)
In-Reply-To: <20190305034834.17280-1-bob.c.feng@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
It's a lot of changes. It looks good to me.
> -----Original Message-----
> From: Feng, Bob C
> Sent: Monday, March 04, 2019 7:49 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C <bob.c.feng@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>
> Subject: [Patch] Document: Update DSC spec to remove EDK related
> contents
> Importance: High
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
>
> Remove EDK related contents inf Dsc spec.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng <bob.c.feng@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Jaben Carsey <jaben.carsey@intel.com>
> ---
> 1_introduction/11_overview.md | 14 +--
> ...=> 210_[components]_section_processing.md} | 27 +-----
> ...ion.md => 211_[userextensions]_section.md} | 4 +-
> ...212_[defaultstores]_section_processing.md} | 4 +-
> .../22_build_description_file_format.md | 50 ++--------
> .../23_[defines]_section_processing.md | 12 +--
> 2_dsc_overview/24_[buildoptions]_section.md | 72 ++------------
> .../26_[libraries]_section_processing.md | 69 --------------
> ...26_[libraryclasses]_section_processing.md} | 4 +-
> ...essing.md => 27_pcd_section_processing.md} | 34 +++----
> ...{29_pcd_sections.md => 28_pcd_sections.md} | 26 ++---
> ...210_pcd_database.md => 29_pcd_database.md} | 4 +-
> ...ctions.md => 310_[components]_sections.md} | 62 +-----------
> ...ns.md => 311_[userextensions]_sections.md} | 4 +-
> ...tion.md => 312_[defaultstores]_section.md} | 4 +-
> 3_edk_ii_dsc_file_format/32_general_rules.md | 13 +--
> .../33_platform_dsc_definition.md | 17 +---
> .../35_[defines]_section.md | 12 +--
> .../36_[buildoptions]_sections.md | 19 ++--
> .../38_[libraries]_sections.md | 94 -------------------
> ...ons.md => 38_[libraryclasses]_sections.md} | 4 +-
> ...310_pcd_sections.md => 39_pcd_sections.md} | 14 +--
> 22 files changed, 101 insertions(+), 462 deletions(-)
> rename 2_dsc_overview/{211_[components]_section_processing.md =>
> 210_[components]_section_processing.md} (84%)
> rename 2_dsc_overview/{212_[userextensions]_section.md =>
> 211_[userextensions]_section.md} (93%)
> rename 2_dsc_overview/{213_[defaultstores]_section_processing.md =>
> 212_[defaultstores]_section_processing.md} (93%)
> delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
> rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md =>
> 26_[libraryclasses]_section_processing.md} (96%)
> rename 2_dsc_overview/{28_pcd_section_processing.md =>
> 27_pcd_section_processing.md} (94%)
> rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md}
> (93%)
> rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md}
> (96%)
> rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md =>
> 310_[components]_sections.md} (81%)
> rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md =>
> 311_[userextensions]_sections.md} (94%)
> rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md =>
> 312_[defaultstores]_section.md} (93%)
> delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md =>
> 38_[libraryclasses]_sections.md} (95%)
> rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md =>
> 39_pcd_sections.md} (97%)
>
> diff --git a/1_introduction/11_overview.md
> b/1_introduction/11_overview.md
> index d9006df..ff2b517 100644
> --- a/1_introduction/11_overview.md
> +++ b/1_introduction/11_overview.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 1.1 Overview
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -48,14 +48,11 @@ specifications.
> This design has the following goals.
>
> **Compatible**
>
> The EDK II DSC format does not support EDK DSC format, nor can EDK tools
> be
> -used to parse the EDK II DSC format files. The EDK II DSC Format must
> maintain
> -backward compatibility for supporting existing EDK INF file formats. This
> means
> -that the changes made to this specification do not require changes for
> standard
> -INF files.
> +used to parse the EDK II DSC format files.
>
> **Simplified platform build and configuration**
>
> One goal of this format is to simplify the build setup and configuration for a
> given platform. It was also designed to simplify the process of adding EDK II
> @@ -67,11 +64,11 @@ builds.
> ###### Table 1 EDK Build Infrastructure Support Matrix
>
> | | EDK DSC | EDK II DSC | EDK FDF | EDK II FDF | EDK INF |
> EDK II INF |
> | ------------------ |:---------:|:------------:|:---------:|:------------:|:---------:|:----
> --------:|
> | EDK Build Tools | YES | NO | YES | NO | YES | NO |
> -| EDK II Build Tools | NO | YES | NO | YES | YES | YES
> |
> +| EDK II Build Tools | NO | YES | NO | YES | NO | YES
> |
>
> **********
> **Note:** This document is intended for persons doing EFI development
> and
> support for different platforms. It is most likely only of interest in the
> event that there is a problem with a build, or if a developer needs to
> perform
> @@ -90,9 +87,6 @@ contain information on the EFI format for FFS or FV file
> creation. The
> Makefiles will support third party compilation tools - Microsoft, Intel and
> GCC
> tool chains - and at least one EDK II tool, GenFw. The GenFw tool is used to
> manipulate the files emitted from the compilation tools.
>
> The EDK II build provides UEFI and PI (Unified EFI, Inc.)
> -specification-compliant images. Use of the tools in the EDK Compatibility
> -package can be used for creating earlier versions of EFI 1.10 and/or UEFI 2.0
> -compliant components. To be clear, EDK II tools do not have the limitation of
> -ECP tools, which can only do EFI 1.10 and UEFI 2.0 images.
> +specification-compliant images.
> diff --git a/2_dsc_overview/211_[components]_section_processing.md
> b/2_dsc_overview/210_[components]_section_processing.md
> similarity index 84%
> rename from 2_dsc_overview/211_[components]_section_processing.md
> rename to 2_dsc_overview/210_[components]_section_processing.md
> index 140f09c..c1948e8 100644
> --- a/2_dsc_overview/211_[components]_section_processing.md
> +++ b/2_dsc_overview/210_[components]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.11 [Components] Section Processing
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,31 +27,24 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.11 [Components] Section Processing
> +## 2.10 [Components] Section Processing
>
> -One or more `[Components]` sections contain lists of EDK components and
> EDK II
> -Modules. The format for specifying the INF file for EDK II modules
> incorporates
> -new scoping capabilities.
> +One or more `[Components]` sections contain lists of EDK II Modules. The
> format
> +for specifying the INF file for EDK II modules incorporates new scoping
> capabilities.
>
> This section uses one or more of the following section definitions:
>
> * `[Components]`
> * `[Components.IA32]`
> * `[Components.X64]`
> * `[Components.EBC]`
> * `[Components.common]`
>
> -EDK components are specified using a fully qualified path to the EDK INF file.
> -
> -`$(EDK_SOURCE)/Path/and/Filename.inf`
> -
> -Because EDK II modules have different requirements than EDK I
> components,
> -specifying the INF filename in the extended DSC file may require more than
> just
> -the INF filename and options. A scoping structure, that binds library class
> +A scoping structure, that binds library class
> (with an optional override instance,) PCD settings (also overriding the values
> specified in the `[PcdsPatchableInModule]` or `[PcdsFixedAtBuild]` sections)
> and build options for an EDK II module may be required. This scoping
> structure,
> containing sub-elements, is enclosed within curly braces: "{}". The opening
> curly brace, "{", must appear at the end of the inf filename line, before any
> @@ -79,20 +72,10 @@ Path/and/Filename.inf {
>
> There are four valid, optional sub-elements for EDK II modules. These
> sub-element are enclosed within angle brackets: `<Defines>,
> <LibraryClasses>`,
> `<Pcds*>` and `<BuildOptions>`.
>
> -For EDK component INF files, an optional sub-element of
> -`<SOURCE_OVERRIDE_PATH>` has been defined. If this element is specified,
> files
> -listed in the directory are used instead of the "same-named" files in the
> -component's directory. If an EDK component directory lists files, A.c, B.c and
> -C.h, and the directory specified in this sub-element contains the file B.c,
> -then the component will be built using files from the component directory:
> A.c
> -and C.h, and the file B.c from the override directory. Any other files listed
> -in the override directory will NOT be included in the build (no new or
> -additional files are permitted).
> -
> An INF file line may also have one argument, EXEC = Filename, that specifies
> an executable file that takes the INF filename as a parameter. The Filename
> must be executable, and must take the INF filename. No other arguments
> are
> permitted to the Filename.
>
> diff --git a/2_dsc_overview/212_[userextensions]_section.md
> b/2_dsc_overview/211_[userextensions]_section.md
> similarity index 93%
> rename from 2_dsc_overview/212_[userextensions]_section.md
> rename to 2_dsc_overview/211_[userextensions]_section.md
> index c176d86..4708e7e 100644
> --- a/2_dsc_overview/212_[userextensions]_section.md
> +++ b/2_dsc_overview/211_[userextensions]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.12 [UserExtensions] Section
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.12 [UserExtensions] Section
> +## 2.11 [UserExtensions] Section
>
> Users may develop custom tools that use the `[UserExtensions]`
> sections.The EDK
> II `[UserExtensions]` sections allow for extending the DSC file with custom
> processing of component images. The format for a user extension section
> specifier is:
> diff --git a/2_dsc_overview/213_[defaultstores]_section_processing.md
> b/2_dsc_overview/212_[defaultstores]_section_processing.md
> similarity index 93%
> rename from 2_dsc_overview/213_[defaultstores]_section_processing.md
> rename to 2_dsc_overview/212_[defaultstores]_section_processing.md
> index 88a7ad2..be83759 100644
> --- a/2_dsc_overview/213_[defaultstores]_section_processing.md
> +++ b/2_dsc_overview/212_[defaultstores]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.13 [DefaultStores] Section Processing
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.13 [DefaultStores] Section Processing
> +## 2.12 [DefaultStores] Section Processing
>
> The contents of this section are used to define DefaultStores names. Default
> store is UEFI HII concept. It is used to define HII default setting for the
> different store, such as standard default, manufacturing default. Platform
> can define the supported default store for DynamicHii/DynamicExHii PCD in
> this
> diff --git a/2_dsc_overview/22_build_description_file_format.md
> b/2_dsc_overview/22_build_description_file_format.md
> index 31e23f4..10dc428 100644
> --- a/2_dsc_overview/22_build_description_file_format.md
> +++ b/2_dsc_overview/22_build_description_file_format.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.2 Build Description File Format
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -229,19 +229,18 @@ definition, contain complete sections, or
> combination of both. And the keyword
> `!include` is case-insensitive.
>
> The argument of this statement is a filename. The file is relative to the
> directory that contains this DSC file, and if not found the tool must attempt
> to find the file relative to the paths listed in the system environment
> -variables `$(WORKSPACE)`, `$(EFI_SOURCE)`, `$(EDK_SOURCE)`, and
> -`$(ECP_SOURCE)`. If the file is still not found, the parsing tools must
> -terminate with an error.
> +variable `$(WORKSPACE)`. If the file is still not found, the parsing tools
> +must terminate with an error.
>
> Macros, defined in this file, are permitted in the path or file name of the
> !include statement, as these files are included prior to processing the file
> -for macros. The system environment variables `$(WORKSPACE)`,
> `$(EDK_SOURCE)`,
> -`$(EFI_SOURCE)`, and `$(ECP_SOURCE)` may also be used; only these
> system
> -environment variables are permitted to start the path of the included file.
> +for macros. The system environment variable `$(WORKSPACE)`, may also be
> used;
> +only these system environment variables are permitted to start the path of
> the
> +included file.
>
> Statements in `!include` files must not break the integrity of the DSC file,
> the included file is read in by tools in the exact position of the file, and is
> functionally equivalent of copying the contents of the included file and
> inserting (paste) the content into the DSC file.
> @@ -395,14 +394,10 @@ reference build (Nt32Pkg/Nt32Pkg.dsc), macros set
> on a command line override
> any macro value defined in the DSC (or FDF) file.
>
> MACROs may also be used as values in PCD statements. See _Section 3.10_
> for
> more information on PCD statements.
>
> -In order to support EDK components and libraries, the word `DEFINE` is
> replaced
> -with `EDK_GLOBAL`. The `EDK_GLOBAL` macros are considered global during
> the
> -processing of the DSC, FDF and EDK INF files.
> -
> Macros that appear within double quotation marks in build options sections
> are
> not expanded. It is assumed that they will be expanded by the OS or
> external
> scripting tools.
>
> Global variables that may be used in EDK II DSC and FDF meta-data files are
> @@ -427,13 +422,10 @@ be altered.
> ###### Table 3 Using System Environment Variable
>
> | Macro Style Used in Meta-Data Files | Matches Windows Environment
> Variable | Matches Linux & OS/X Environment Variable |
> | ----------------------------------- | ------------------------------------ | ---------------
> -------------------------- |
> | $(WORKSPACE) | %WORKSPACE% | $WORKSPACE
> |
> -| $(EFI_SOURCE) | %EFI_SOURCE% | $EFI_SOURCE
> |
> -| $(EDK_SOURCE) | %EDK_SOURCE% |
> $EDK_SOURCE |
> -| $(ECP_SOURCE) | %ECP_SOURCE% | $ECP_SOURCE
> |
> | $(EDK_TOOLS_PATH) | %EDK_TOOLS_PATH% |
> $EDK_TOOLS_PATH |
>
> The system environment variables, PACKAGES_PATH and EDK_TOOLS_BIN,
> are not
> permitted in EDK II meta-data files.
>
> @@ -479,22 +471,11 @@ follow the same rules as architectural modifiers.
> # Can use $(MDE) from the common section
> PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
>
> TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
> ```
>
> -### 2.2.7 EDK_GLOBAL
> -
> -The `EDK_GLOBAL` statements defined in the DSC file can be used during
> the
> -processing of the DSC, FDF and EDK INF files. The definition of the
> -`EDK_GLOBAL` name must only be done in the DSC `[Defines]` section.
> These
> -special macros can be used in path statements, DSC file `[BuildOptions]` and
> -FDF file `[Rule]` sections. These statements are used to replace the
> -environment variables that were defined for the EDK build tools. They must
> -never be used in a conditional directive statement in the DSC and FDF files,
> -nor can they be used by EDK II INF files.
> -
> -### 2.2.8 Conditional Directive Statements (!if...)
> +### 2.2.7 Conditional Directive Statements (!if...)
>
> Conditional directive statements are used by the build tools preprocessor
> function to include or exclude statements in the DSC file. A limited number
> of
> statements are supported, and nesting of conditionals is also supported.
> Statements are prefixed by the exclamation "!" character. Conditional
> @@ -642,11 +623,11 @@ The following are examples of conditional
> directives.
> !else
> # The strings do not match exactly
> !endif
> ```
>
> -### 2.2.9 !error Statement
> +### 2.2.8 !error Statement
>
> The `!error` statement may appear within any section of EDK II DSC file. The
> argument of this statement is an error message, it causes build tool to stop
> at the location where the statement is encountered and error message
> following
> the `!error` statement is output as a message. The keyword `!error` is not
> @@ -658,11 +639,11 @@ The following example show the valid usage of the
> `!error` statement.
> !if $(FEATURE_ENABLE) == TRUE
> !error "unsupported feature!"
> !endif
> ```
>
> -### 2.2.10 Expressions
> +### 2.2.9 Expressions
>
> Expressions can be used in conditional directive comparison statements and
> in
> value fields for Macros and PCDs in the DSC and FDF files.
>
> Refer to the EDK II Expression Syntax Specification for additional
> information.
> @@ -723,11 +704,11 @@ names specified on the command line or come
> from the `Conf/target.txt` file.
>
> For logical expressions, any non-zero value must be considered `TRUE`.
>
> Invalid expressions must cause a build break with an appropriate error
> message.
>
> -### 2.2.11 Section Handling
> +### 2.2.10 Section Handling
>
> The DSC file parsing routines must process the sections so that common
> architecture sections are logically merged with the architecturally specific
> sections. The architectural sections need to be processed so that they are
> logically after the common section. It is recommended that EDK II
> developers
> @@ -750,24 +731,13 @@ on the "==" replace or "=" append assignment
> character sequence.
>
> ```ini
> [BuildOptions.Common]
> MSFT:*_*_*_CC_FLAGS = /nologo
>
> -[BuildOptions.Common.EDK]
> - MSFT:*_*_*_CC_FLAGS = /Od
> -
> [BuildOptions.IA32]
> MSFT:*_*_IA32_CC_FLAGS = /D EFI32
> ```
>
> For IA32 architecture builds of an EDK II INF file would logically be:
>
> `MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32`
>
> -For non-IA32 architecture EDK INF files, tool parsing would logically be:
> -
> -`MSFT:*_*_*_CC_FLAGS = /nologo /Od`
> -
> -For IA32 architecture builds of an EDK INF file, tool parsing would logically
> -be:
> -
> -`MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32 /Od`
> diff --git a/2_dsc_overview/23_[defines]_section_processing.md
> b/2_dsc_overview/23_[defines]_section_processing.md
> index 428196b..ad0702b 100644
> --- a/2_dsc_overview/23_[defines]_section_processing.md
> +++ b/2_dsc_overview/23_[defines]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.3 [Defines] Section Processing
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -80,14 +80,10 @@ define the MACRO name during the processing of this
> file, files included by the
> **Warning:** The DEFINE MACRO = Value statements in other sections are
> local to
> the section, and override the global definition for entries in the section that
> follow the macro definition: `DEFINE MACRO = Value.`
> **********
>
> -The `EDK_GLOBAL MACRO = Value` definitions in this section globally define
> the
> -MACRO name when parsing the DSC, files included by the !include
> statement, FDF
> -and EDK INF files.
> -
> The EDK II tools will locate the FDF file specified in the `FLASH_DEFINITION`
> entry in the same directory as the DSC file. When the
> PCD_VAR_CHECK_GENERATION
> entry is present and set to TRUE, tools will generate a binary file for
> DynamicHii and DynamicExHii PCD variable checking.
>
> @@ -112,11 +108,10 @@ item is required.
> | `BUILD_NUMBER` | Optional | Up to four digit numbers | Set
> this value in the generated Makefile.
> |
> | `FIX_LOAD_TOP_MEMORY_ADDRESS` | Optional | Address |
> The top memory address - the starting location in memory for all drivers,
> application loading. When it is not set, or set to 0, the load fixed address
> feature will be disabled. When it is set to 0xFFFFFFFFFFFFFFFF, enable the
> feature as fixed offset to TOLM. When it is set to the positive address,
> enable the feature as fixed address. |
> | `TIME_STAMP_FILE` | Optional | Filename | The
> timestamp file contains a timestamp that will be used to set the creation
> timestamp on all created files. If this file is specified, it will be used to adjust
> the timestamp of created files, if it does not exist at the start of a build, the
> file will be created, using the current date and time.
> |
> | | | | If this variable is not specified,
> the time and date of the start of the build are used by the EDK II tools that
> modify the time/date portion of a PE32/PE32+/Coff header. This file's path is
> either relative to the directory containing the DSC file or a `WORKSPACE`[^1]
> relative path followed by the file name.
> |
> | `DEFINE` | Optional | MACRO = PATH or Value | A name
> that is assigned to either a path or a value. This statement can be used to
> make the DSC file more readable, as in: `DEFINE MDE = MdePkg/Library`
> Then, later, `$(MDE)/BaseLib/ BaseLib.inf`
> |
> -| `EDK_GLOBAL` | Optional | MACRO = PATH or Value |
> Similar to the DEFINE statement, macros defined using this keyword are only
> valid when processing EDK ibraries and components. These values are
> ignored during processing of EDK II modules.
> |
> | `RFC_LANGUAGES` | Optional | RFC4646 Language code list | A
> semi-colon ";" separated list of RFC4646 Language codes (EDK II Modules)
> used during the generation of only a set, rather than all, UNICODE languages
> during the StrGather AutoGen phase. The list must be encapsulated in
> double quotes.
> |
> | `ISO_LANGUAGES` | Optional | ISO-639-2 Language code list | A
> non-separated list of three character ISO 639-2 Language codes (EDK
> Components) used during the generation of only a set, rather than all,
> UNICODE languages during the StrGather AutoGen phase. The list must be
> encapsulated in double quotes.
> |
> | `VPD_TOOL_GUID` | Optional | Registry Format GUID |
> When this element is present, the build process will be interrupted during
> the AutoGen stage in order to call an external program, named by GUID that
> must also be defined in the Conf/tools_def.txt file using a tool code name of
> VPDTOOL. Refer to the EDK II Build specification for additional information.
> |
> | `PCD_INFO_GENERATION` | Optional | TRUE or FALSE | If
> present, and set to TRUE, this flag will generate PCD information in the Pcd
> Database.
> |
> | `PCD_VAR_CHECK_GENERATION` | Optional | TRUE or FALSE |
> If present and set to TRUE, this flag will generate the variable validation table
> binary file in the build output FV floder. If not present ro set to FALSE, then
> the binary file will not be generated.
> |
> @@ -128,9 +123,8 @@ WORKSPACE system environment variable and the
> PACKAGES_PATH system environment
> variable.
>
> **********
> **Note:** EDK II Modules can have unicode string files that contain RFC4646
> language codes. EDK II modules cannot have unicode string files that contain
> -ISO-629-2 language codes. USI-629-2 language codes are only valid for EDK
> -components. The format of the statement is specific to processing RFC4646
> -language code lists.
> +ISO-629-2 language codes. The format of the statement is specific to
> processing
> +RFC4646 language code lists.
> **********
> diff --git a/2_dsc_overview/24_[buildoptions]_section.md
> b/2_dsc_overview/24_[buildoptions]_section.md
> index 7d3d2d1..375866c 100644
> --- a/2_dsc_overview/24_[buildoptions]_section.md
> +++ b/2_dsc_overview/24_[buildoptions]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.4 [BuildOptions] Section
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -33,11 +33,11 @@
>
> Content in the `[BuildOptions]` section is used to define module specific tool
> chain flags rather than use the default flags for a module. These flags are
> appended to any standard flags that are defined by the build process. They
> can
> be applied for any modules or those modules on the specific ARCH or those
> -modules with the specific module style (EDK or EDKII). In order to replace
> the
> +modules with the specific EDKII module style. In order to replace the
> standard flags that are defined by the build process, an alternate assignment
> operator is used; "==" is used for replacement, while "=" is used to append
> the flag lines. In addition to flags, other tool attributes may have the item
> either appended or replaced.
>
> @@ -94,93 +94,35 @@ that the lines show use of the "\" line continuation
> character.
> ```
>
> The following examples show how `[BuildOptions]` sections can be merged,
> as
> well as how the content in those sections can be merged.
>
> -For specific flag values, common to both EDK and EDKII options, it is
> -appropriate to use a `DEFINE` statement in the `[Defines]` section; for
> +It is appropriate to use a `DEFINE` statement in the `[Defines]` section; for
> example 1:
>
> `DEFINE MSFT_COMMON_DEBUG_FLAGS = /Od`
>
> Then the macro, $(MSFT_COMMON_DEBUG_FLAGS) can be used in
> statements in any of
> the `[BuildOptions.*]` sections, as in:
>
> ```ini
> -[BuildOptions.Common.EDK]
> +[BuildOptions.X64]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> $(MSFT_COMMON_DEBUG_FLAGS)
>
> -[BuildOptions.Common.EDKII]
> +[BuildOptions.IA32]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> $(MSFT_COMMON_DEBUG_FLAGS)
> ```
>
> It is also permissible to have a `[BuildOptions.<arch>]` section that can be
> shared be used for different statements that are not duplicate content from
> -either the `[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]`
> -sections. For example 2:
> +the `[BuildOptions.<arch>.EDKII]` sections. For example:
>
> ```ini
> [BuildOptions.Common]
> MSFT:*_*_*_ASL_OUTFLAGS = /Fo=
>
> -[BuildOptions.Common.EDK]
> - MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
> -
> [BuildOptions.Common.EDKII]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
>
> [BuildOptions.IA32.EDKII]
> MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
> -```
> -
> -It is also permissible to have a `[BuildOptions.<arch>]` section that can be
> -shared be used prior to appending statement content from either the
> -`[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]` sections as in
> the
> -following example:
> -
> -```ini
> -[BuildOptions.IA32]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /nologo /W4 /WX /Gy /c /D UNICODE
> -
> -[BuildOptions.IA32.EDKII]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
> -```
> -
> -When processing EDK II C files, the `CC_FLAGS` would be:
> -
> -`/nologo /W4 /WX /Gy /c /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
> -
> -While processing of EDK C files, the CC_FLAGS would be:
> -
> -`/nologo /W4 /WX /Gy /c /D UNICODE /D EFI32`
> -
> -It is also permissible to combine [BuildOptions.common] with
> -`[BuildOptions.<arch>]` sections that are not "common", as in the following
> -example:
> -
> -```ini
> -[BuildOptions.Common]
> - MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> -
> -[BuildOptions.IA32]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy /D UNICODE
> -
> -[BuildOptions.IA32.EDKII]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
> -```
> -
> -In the previous example, the `CC_FLAGS` for IA32 EDK II modules would
> equal:
> -
> -`/nologo /x /W4 /WX /Gy /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
> -
> -The CC_FLAGS for IA EDK modules would equal:
> -
> -`/nologo /c /W4 /WX /Gy /D UNICODE /D EFI32`
> +```
> \ No newline at end of file
> diff --git a/2_dsc_overview/26_[libraries]_section_processing.md
> b/2_dsc_overview/26_[libraries]_section_processing.md
> deleted file mode 100644
> index 82cda47..0000000
> --- a/2_dsc_overview/26_[libraries]_section_processing.md
> +++ /dev/null
> @@ -1,69 +0,0 @@
> -<!--- @file
> - 2.6 [Libraries] Section Processing
> -
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> -
> - Redistribution and use in source (original document form) and 'compiled'
> - forms (converted to PDF, epub, HTML and other formats) with or without
> - modification, are permitted provided that the following conditions are met:
> -
> - 1) Redistributions of source code (original document form) must retain the
> - above copyright notice, this list of conditions and the following
> - disclaimer as the first lines of this file unmodified.
> -
> - 2) Redistributions in compiled form (transformed to other DTDs, converted
> to
> - PDF, epub, HTML and other formats) must reproduce the above copyright
> - notice, this list of conditions and the following disclaimer in the
> - documentation and/or other materials provided with the distribution.
> -
> - THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND
> ANY EXPRESS OR
> - IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES OF
> - MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED. IN NO
> - EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT LIMITED TO,
> - PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
> OR PROFITS;
> - OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> LIABILITY,
> - WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> NEGLIGENCE OR
> - OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> - ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> -
> --->
> -
> -## 2.6 [Libraries] Section Processing
> -
> -This section specifies all the EDK INF files that must be processed to build
> -the libraries used to build the individual EDK components. This will include
> -all the libraries called out in the individual component INF files. A sample
> -section is listed below. Each line from the libraries section specifies a
> -library component's INF file (relative to `$(EDK_SOURCE)`, or absolute path).
> -
> -This section is required for any EDK II DSC file that specifies one or more EDK
> -components. If only EDK II Modules are used, this section must not be
> -specified. If the section is specified, and only EDK II Modules are found, the
> -build and parsing tools will ignore this section. A warning message will be
> -emitted by the parsing tool if and only the parsing tool is executed in a
> -verbose mode.
> -
> -The `!include` statements may be used within the `[Libraries]` section.
> -
> -The file specified after the `!include` statement can only contain a list of
> -EDK Library INF files (with the path to the file). If the line starts with a
> -word, rather than a variable like `$(EDK_SOURCE)` the path is assumed to be
> -relative to `$(EDK_SOURCE)`. Again, only EDK Library INF files are permitted
> in
> -the file specified in the `!include` statement.
> -
> -This section will typically use one of the following section definitions:
> -
> -```ini
> -[Libraries.common]
> -[Libraries.IA32]
> -[Libraries.X64]
> -[Libraries.EBC]
> -```
> -
> -The formats for entries in this section is:
> -
> -```
> -$(EDK_SOURCE)/Path/to/LibraryName.inf
> -$(CUSTOM_DECOMPRESS_LIB_INF)
> -```
> diff --git a/2_dsc_overview/27_[libraryclasses]_section_processing.md
> b/2_dsc_overview/26_[libraryclasses]_section_processing.md
> similarity index 96%
> rename from 2_dsc_overview/27_[libraryclasses]_section_processing.md
> rename to 2_dsc_overview/26_[libraryclasses]_section_processing.md
> index 50bda93..0f87ceb 100644
> --- a/2_dsc_overview/27_[libraryclasses]_section_processing.md
> +++ b/2_dsc_overview/26_[libraryclasses]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.7 [LibraryClasses] Section Processing
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.7 [LibraryClasses] Section Processing
> +## 2.6 [LibraryClasses] Section Processing
>
> The `[LibraryClasses]` section is used to provide a mapping between the
> library
> class names used by an EDK II module and the Library Instances that are
> selected by the platform integrator. Library Classes allow modules to be
> coded
> for a library class, and then allow platform integrator then chooses a Library
> diff --git a/2_dsc_overview/28_pcd_section_processing.md
> b/2_dsc_overview/27_pcd_section_processing.md
> similarity index 94%
> rename from 2_dsc_overview/28_pcd_section_processing.md
> rename to 2_dsc_overview/27_pcd_section_processing.md
> index a5d56b3..d2a409f 100644
> --- a/2_dsc_overview/28_pcd_section_processing.md
> +++ b/2_dsc_overview/27_pcd_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.8 PCD Section Processing
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,22 +27,22 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.8 PCD Section Processing
> +## 2.7 PCD Section Processing
>
> This section is for specifying global (or default) PCD values as well as the
> access method each PCD will use for modules in the platform.
>
> -### 2.8.1 PCD Access Methods
> +### 2.7.1 PCD Access Methods
>
> There are five defined PCD access methods. The five access methods are:
> `FeatureFlag`, `FixedAtBuild`, `PatchableInModule`, `Dynamic` and
> `DynamicEx`
> PCDs.
>
> -#### 2.8.1.1 FeatureFlag and Dynamic PCD Types
> +#### 2.7.1.1 FeatureFlag and Dynamic PCD Types
>
> The two recommended access methods that are commonly used in modules
> are
> `FeatureFlag` and the generic `Dynamic method`. The `Dynamic` form is used
> for
> configuration when the PCD value is produced and consumed by drivers
> during
> execution, the value may be user configurable from setup or the value is
> @@ -50,11 +50,11 @@ produced by the platform in a specified area. It is
> associated with modules
> that are released in source code. The dynamic form is the most flexible
> method,
> as platform integrators may chose a to use a different access method for a
> given platform without modifying the module's INF file or the code for the
> module.
>
> -#### 2.8.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access
> Methods
> +#### 2.7.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access
> Methods
>
> Similar in function, the `DynamicEx` access method can be used with
> modules
> that are released as binary. The `FixedAtBuild` and `PatchableInModule`
> PCDs
> are static and only the `PatchableInModule` PCD can have the value changed
> in a
> binary prior to including the module in a firmware image.
> @@ -82,11 +82,11 @@ The content in these sections is used for generating
> the `AutoGen.c` and
> [Pcds(PcdType).IA32]
> [Pcds(PcdType).X64]
> [Pcds(PcdType).EBC]
> ```
>
> -### 2.8.2 PCD Access Method Categories
> +### 2.7.2 PCD Access Method Categories
>
> Of the five access methods of PCDs that have been defined, they fall into
> one
> of three categories:
>
> * `FeatureFlag` - always has a Boolean value.
> @@ -129,42 +129,42 @@ different datum type based on the architecture.
> For example, a PCD that is used
> for address manipulation may have a datum type of `UINT32` for IA32 and
> `UINT64` for X64 and EBC architectures. This will be declared in the EDK II
> Package Declaration (DEC) File.
> **********
>
> -### 2.8.3 PCD Section Usage
> +### 2.7.3 PCD Section Usage
>
> PCD sections are optional unless the EDK II modules specified in the
> `[Components]` section use PCDs.
>
> The PCD sections are used to define the access method for a PCD. Since each
> module is built once for a given architecture, the PCD can be listed under
> different PCD access methods provided they are listed under different
> architectures.
>
> -#### 2.8.3.1 Access Methods
> +#### 2.7.3.1 Access Methods
>
> However, once a PCD access method is selected for a given architecture, the
> PCD
> can only use that access method.
>
> #### Example
>
> A PCD that will use the `FixedAtBuild` access method for IA32 cannot use the
> `PatchableInModule` access method for individual modules built for the IA32
> architecture.
>
> -#### 2.8.3.2 Different Access Methods
> +#### 2.7.3.2 Different Access Methods
>
> It is permissible to have a PCD use different access methods for different
> architectures.
>
> #### Example
>
> A PCD that will use the FixedAtBuild access method for IA32 can use the
> Patchable in Module access method for X64.
>
> -#### 2.8.3.3 Item Access Methods
> +#### 2.7.3.3 Item Access Methods
>
> Multiple item access methods, `PcdsFeatureFlag`, `PcdsFixedAtBuild`,
> `PcdsPatchableInModule`, `PcdsDynamic` and `PcdsDynamicEx` are not
> allowed to
> be specified within a single [] section tag.
>
> @@ -187,11 +187,11 @@ be specified within a single [] section tag.
> [PcdsDynamicDefault.IA32]
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> ```
>
> -#### 2.8.3.4 Mixing PCD Dynamic item storage methods
> +#### 2.7.3.4 Mixing PCD Dynamic item storage methods
>
> It is not permissible to mix different PCD Dynamic item storage methods
> within
> a single section, as the format for the PCD entries in PcdsDynamicDefault,
> PcdsDynamicVpd, PcdsDynamicHii, and PcdsDynamicExDefault,
> PcdsDynamicExVpd and
> PcdsDynamicExHii sections are different.
> @@ -212,11 +212,11 @@ PcdsDynamicExHii sections are different.
>
> [PcdsDynamicExVpd.IA32]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|*|0
> ```
>
> -#### 2.8.3.5 Multiple Architectural Section Tags
> +#### 2.7.3.5 Multiple Architectural Section Tags
>
> It is permissible to specify multiple architectural section tags for the same
> PCD item type in a single section.
>
> #### Example
> @@ -232,11 +232,11 @@ PCD item type in a single section.
> [PcdsDynamicDefault.IA32, PcdsDynamicDefault.X64]
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> ```
>
> -#### 2.8.3.6 Dynamic and DynamicEx PCD Storage Methods
> +#### 2.7.3.6 Dynamic and DynamicEx PCD Storage Methods
>
> The PCDs that use Dynamic and DynamicEx access methods can have their
> values
> stored in one of three different methods, Default, VPD or HII. A PCD using
> one
> of these access methods can use one storage method. It is not permissible
> to
> have a PCD try to store the data in the Default database and a VPD region at
> @@ -273,11 +273,11 @@
> TokenSpaceGuid.PcdCname|<HiiString>|<VariableGuid>|<VariableOffset>|
> <Value>|<Att
> **********
> **Note:** Some of the above fields are optional; refer to "PCD Sections" in
> the
> next chapter for the exact syntax.
> **********
>
> -#### 2.8.3.7 Unique PCDs
> +#### 2.7.3.7 Unique PCDs
>
> Unique PCDs are identified using the format to identify the named PCD:
>
> `TokenSpaceGuidCName.PcdCName`
>
> @@ -304,11 +304,11 @@ be used - `PcdsFixedAtBuild` for modules with
> wellknown values for a PCD,
> then either `PcdsPatchableInModule` or `PcdsDynamicEx` - the first
> being for testing a module, the second giving the ability for doing individual
> driver performance tuning "on-the-fly".
> **********
>
> -#### 2.8.3.8 Precedence
> +#### 2.7.3.8 Precedence
>
> Tools must assume that the first method found for a PCD in the PCDs
> sections
> will used for all instances of a PCD. Tools must not allow for different
> modules using a PCD differently, using the `<Pcds*>` statements under the
> INF
> file definitions in the `[Components]` section.
> @@ -375,11 +375,11 @@ listed more than one time within a section. List a
> PCD in one of the other
> access methods is allowed, provided a single access method must be used
> for all
> instances of the PCD. If PCD field value is listed, it will override PCD value
> even if PCD value is after PCD field value.
> **********
>
> -#### 2.8.3.9 Library Instances
> +#### 2.7.3.9 Library Instances
>
> Library Instances that use PCDs that the module is linked with must use the
> same PCD setting as the module using the Library Instance. So if a module
> uses
> a PCD as `PcdsFixedAtBuild`, then all library instances that use that PCD must
> also use the PCD as `PcdsFixedAtBuild` with the same value.
> @@ -393,11 +393,11 @@ The expression is a C-style expression using C
> relational, equality and logical
> numeric and bitwise operators or numeric and bitwise operators that
> evaluate to
> a value that matches the PCD's Datum Type (specified in the DEC package
> declaration file.) Precedence and associativity follow C standards. Using PCDs
> in expressions is also permitted.
>
> -#### 2.8.3.10 Maximum Size of a VOID* PCD
> +#### 2.7.3.10 Maximum Size of a VOID* PCD
>
> If the maximum size of a VOID* PCD is not specified in the DSC file, then the
> maximum size will be calculated based on the largest size of the following:
>
> * the string or array in the --pcd option
> diff --git a/2_dsc_overview/29_pcd_sections.md
> b/2_dsc_overview/28_pcd_sections.md
> similarity index 93%
> rename from 2_dsc_overview/29_pcd_sections.md
> rename to 2_dsc_overview/28_pcd_sections.md
> index d84d2f4..0b0b6d3 100644
> --- a/2_dsc_overview/29_pcd_sections.md
> +++ b/2_dsc_overview/28_pcd_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.9 PCD Sections
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,13 +27,13 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.9 PCD Sections
> +## 2.8 PCD Sections
>
> -### 2.9.1 [PcdsFeatureFlag] section
> +### 2.8.1 [PcdsFeatureFlag] section
>
> The required content for the FeatureFlag PCD is the PCD Token Space Guid C
> name, the PCD's C name (these two entries are separated by the period
> character), and a Boolean value of either TRUE, FALSE, 1 or 0. The PCD name
> and value entries are separated by the pipe "|" character.
> @@ -69,19 +69,19 @@ Format of an entry in this section is:
> ```ini
> [PcdsFeatureFlag.common]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxePcdDatabaseTraverseEnabled|1
> ```
>
> -### 2.9.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
> +### 2.8.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
>
> The section modifier, `SkuIdentifier`, can be used by the build tools to create
> images for one specific SKU. Unlike the `PcdsDynamic` and `PcdsDynamicEx`
> entries, no access methods are allowed for having different values during
> runtime for different SKUs. Do not use the `SkuIdentifier` when building all
> SKUs.
>
> -#### 2.9.2.1 PcdsFixedAtBuild
> +#### 2.8.2.1 PcdsFixedAtBuild
>
> The `FixedAtBuild` PCD access method cannot be used in a Binary Module.
>
> The required content for the `FixedAtBuild` PCD are the PCD Token Space
> Guid
> C name, the PCD's C name (these two entries are separated by the period
> @@ -125,11 +125,11 @@ Format for Boolean and numeric entries in this
> section is:
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock|200000000
> gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
>
> gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtPhysicalDisk|L"E:RW;245760;512"
> |VOID*|32
> ```
>
> -#### 2.9.2.2 PcdsPatchableInModule
> +#### 2.8.2.2 PcdsPatchableInModule
>
> The `PatchableInModule` PCD access method can be used with modules that
> are
> distributed in binary form. The PCD's value can be patched by tools that
> know
> the offset of the PCD into the binary file.
>
> @@ -163,11 +163,11 @@ Format of an entry in this section is:
> ```ini
> [PcdsPatchableInModule.common]
>
> gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000|UINT32|
> 4
> ```
>
> -### 2.9.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
> +### 2.8.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
>
> PCDs listed in these sections cannot be used in conditional directive
> statements.
>
> The Dynamic PCD access method cannot be used for modules that are
> distributed
> @@ -185,11 +185,11 @@ binary image supports multiple SKUs. The SKU
> selection based on things like a
> hardware jumper, or some other method that is outside the scope of this
> document.
>
> For using the standard PCD Get/Set PPI or Protocol.
>
> -#### 2.9.3.1 PcdsDynamicDefault
> +#### 2.8.3.1 PcdsDynamicDefault
>
> The Dynamic Default PCD access method will generate a volatile variable that
> can be accessed at runtime using PCD a Get PPI or Protocol.
>
> ```ini
> @@ -213,11 +213,11 @@ The format for a VOID* PCD entry in this section is:
> [PcdsDynamicDefault]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
> ```
>
> -#### 2.9.3.2 PcdsDynamicHII
> +#### 2.8.3.2 PcdsDynamicHII
>
> The Dynamic Hii PCD access method will generate HII data content that can
> be
> accessed at runtime.
>
> For using the HII for PCD data, the section name is as follows:
> @@ -259,11 +259,11 @@ described in the following table.
>
> [PcdsDynamicHii.common.DEFAULT]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfi
> GlobalVariableGuid|0x07|0|BS,RT,NV
> ```
>
> -#### 2.9.3.3 PcdsDynamicVpd
> +#### 2.8.3.3 PcdsDynamicVpd
>
> The Dynamic Vpd PCD access method will generate macros that allow the
> data
> content (stored in read-only memory) to be accessed at runtime. Note that
> the
> PCD drivers may use a copy of the VPD data to allow runtime changes to
> these
> variables.
> @@ -296,11 +296,11 @@ The format for VOID* datum type content in this
> section is:
> gNoSuchTokenSpaceGuid.PcdOemBootOptionName | 0x22D4 | 100 | " " #
> VOID*
> gNoSuchTokenSpaceGuid.PcdOemBootOptionPath | 0x2338 | 100 | " " #
> VOID*
> gNoSuchTokenSpaceGuid.PcdEnableFastBoot | 0x239C | 1 | FALSE #
> BOOLEAN
> ```
>
> -#### 2.9.3.4 PcdsDynamicExDefault
> +#### 2.8.3.4 PcdsDynamicExDefault
>
> The DynamicEx access method of PCD is recommended for modules that are
> distributed in binary form.
>
> Entries for `DynamicEx` are identical to the `Dynamic` entries. The
> `DynamicEx`
> @@ -327,11 +327,11 @@ The format for a VOID* PCD entry in this section is:
> [PcdsDynamicExDefault.common.DEFAULT]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
> ```
>
> -#### 2.9.3.5 PcdsDynamicEx Hii
> +#### 2.8.3.5 PcdsDynamicEx Hii
>
> For using the HII for PCD data, the section name is as follows:
>
> `[PcdsDynamicExHii.$(arch).$(SKUID_IDENTIFIER)]`
>
> @@ -357,11 +357,11 @@ described in Table 9 HII Attributes.
>
> [PcdsDynamicExHii.common.DEFAULT]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfi
> GlobalVariableGuid|0x07|0|BS,RT,NV
> ```
>
> -#### 2.9.3.6 PcdsDynamicExVpd
> +#### 2.8.3.6 PcdsDynamicExVpd
>
> For using the VPD for PCD data, the section name is:
>
> `[PcdsDynamicExVpd.$(arch).$(SKUID_IDENTIFIER)]`
>
> diff --git a/2_dsc_overview/210_pcd_database.md
> b/2_dsc_overview/29_pcd_database.md
> similarity index 96%
> rename from 2_dsc_overview/210_pcd_database.md
> rename to 2_dsc_overview/29_pcd_database.md
> index 2e4380c..ab3fda5 100644
> --- a/2_dsc_overview/210_pcd_database.md
> +++ b/2_dsc_overview/29_pcd_database.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.10 PCD Database
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.10 PCD Database
> +## 2.9 PCD Database
>
> Dynamic and DynamicEx PCDs can be modified during the boot/setup stages.
> In
> order to support modifications, a PEIM and a DXE driver use databases of
> these
> PCDs so that changes can persist across reboots. These databases are
> generated
> prior to the final image assembly. The following rules determine when the
> build
> diff --git a/3_edk_ii_dsc_file_format/311_[components]_sections.md
> b/3_edk_ii_dsc_file_format/310_[components]_sections.md
> similarity index 81%
> rename from 3_edk_ii_dsc_file_format/311_[components]_sections.md
> rename to 3_edk_ii_dsc_file_format/310_[components]_sections.md
> index b8e2875..abca3e9 100644
> --- a/3_edk_ii_dsc_file_format/311_[components]_sections.md
> +++ b/3_edk_ii_dsc_file_format/310_[components]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.11 [Components] Sections
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.11 [Components] Sections
> +## 3.10 [Components] Sections
>
> The `[Components]` sections are required.
>
> #### Summary
>
> @@ -42,12 +42,11 @@ files.
> The `!include` statement is permitted in `[Components]` sections. however
> this
> method is NOT recommended.
>
> All EDK II file paths must be specified relative to a directory containing EDK
> II Packages (as specified by the WORKSPACE or a directory listed in
> -PACKAGES_PATH system environment variable). EDK INF component and
> library files
> -may use `$(EDK_SOURCE)` or `$(EFI_SOURCE)` global environment variables.
> If the
> +PACKAGES_PATH system environment variable). If the
> environment variable is not specified, the INF file path is assumed to be
> relative to the `WORKSPACE`.
>
> The following is an example of specifying a `WORKSPACE` (MdeModulePkg is
> in the
> directory pointed to by the WORKSPACE environment variable) relative
> Path:
> @@ -55,11 +54,11 @@ directory pointed to by the WORKSPACE environment
> variable) relative Path:
> `MdeModulePkg/Universal/Disk/DiskIo/Dxe`
>
> The following is an example of specifying an Indirect Path:
>
> ```ini
> -DEFINE FOUNDATION_LIB = $(EDK_SOURCE)/Foundation/Library
> +DEFINE FOUNDATION_LIB = $(WORKSPACE)/Foundation/Library
> $(FOUNDATION_LIB)/EdkIIGlueLib/EntryPoints
> ```
>
> The permitted `DEFINE` statement must be a variable name assigned to a
> path.
>
> @@ -91,13 +90,10 @@ value, while the `<PcdsFixedAtBuild>` section of an
> INF use a different value.
> The FeatureFlag PCD and the two dynamic forms of PCDs are common to a
> platform,
> with the dynamic form PCD values stored in a "runtime database", read-only
> memory location or an HII data store. Therefore, having different values is
> prohibited for these access methods.
>
> -EDK components may have the scoped sub-element,
> `<SOURCE_OVERRIDE_PATH>` that
> -is used to virtually replace files in the component's directory.
> -
> The format for items listed in the sub-elements is the identical format for
> content under the section.
>
> Within the context of an EDK II module sub-element, the `<LibraryClasses>`
> entries must appear before `<Pcds*>` entries; the `<LibraryClasses>` entries
> @@ -128,20 +124,16 @@ modules in a binary image (the FDF file describes
> that ordering).
> <attribs> ::= <attrs> ["," <TS> "Components" <attrs>]*
> <attrs> ::= "." <arch>
> <ModuleStatements> ::= {<MacroDefinition>}
> {<IncludeStatement>} {<TS> <InfFiles>}
> <InfFiles> ::= <InfFilename> [<MTS> <Options>] <EOL>
> -<Options> ::= {<Exec>} {<Edk2Struct>} {<EdkStruct>}
> +<Options> ::= {<Exec>} {<Edk2Struct>}
> <InfFilename> ::= <PATH> <Word> ".inf"
> <Exec> ::= "EXEC" <Eq> <ExecFilename>
> <ExecFilename> ::= <PATH> <Word> ["." <ExecExtension>]
> <ExecExtension> ::= <Word> # An OS recognisable extension that will #
> automatically be run.
> -<EdkStruct> ::= "{" <EOL>
> - <TS> "<SOURCE_OVERRIDE_PATH>" <EOL>
> - <TS> <PATH>
> - <TS> "}" <EOL>
> <Edk2Struct> ::= "{" <EOL>
> [<TS> <DefSec>]
> [<TS> <LibraryClasses>]
> [<TS> <PcdsFeatureFlag>]
> [<TS> <PcdsFixed>]
> @@ -267,49 +259,5 @@ individual modules.
>
> **_ClassName_**
>
> A Library Class Keyword defined in DEC files. The Keyword must also be
> present
> in the defines section `LIBRARY_CLASS` entry of the INF file
> -
> -#### Example Using EDK components in an EDK II DSC build
> -
> -```
> -[Components]
> -DEFINE EDK=$(EDK_SOURCE)/Edk
> -DEFINE MDE=MdePkg/Library
> -DEFINE STATUS_CODE=$(MDE)/PeiDxeDebugLibReportStatusCode
> -
> -$(EDK)/Foundation/Core/Pei/PeiMain.inf
> -DEFINE NT32 = $(EDK)/Sample/Platform
> -$(NT32)/Generic/MonoStatusCode/Pei/Nt32/MonoStatusCode.inf
> -$(NT32)/Nt32/Pei/BootMode/BootMode.inf
> -$(NT32)/Nt32/Pei/FlashMap/FlashMap.inf
> -MdeModulePkg/Core/Dxe/DxeMain.inf
> -...
> -MdeModulePkg/Universal/Debugger/Debugport/Dxe/DebugPort.inf
> -MdeModulePkg/Cpu/DebugSupport/Dxe/DebugSupport.inf
> -...
> -
> -DEFINE MDEMODUNI = MdeModulePkg/Universal
> -$(MDEMODUNI)/DataHub/DataHubStdErr/Dxe/DataHubStdErr.inf
> -MdeModulePkg/Universal/Disk/DiskIo/Dxe/DiskIo.inf {
> - <LibraryClasses>
> - DebugLib|$(STATUS_CODE)/PeiDxeDebugLibReportStatusCode.inf
> - BaseMemoryLib|$(MDE)/DxeMemoryLib/DxeMemoryLib.inf
> -
> MemoryAllocationLib|$(MDE)/DxeMemoryAllocationLib/DxeMemoryAllocati
> onLib.inf
> - <PcdsFeatureFlag>
> - PcdDriverDiagnosticsDisable|gEfiMdePkgTokenSpaceGuid|FALSE
> -}
> -MdeModulePkg/Universal/Ebc/Dxe/Ebc.inf
> -$(MDEMODUNI)/GenericMemoryTest/Dxe/NullMemoryTest.inf
> -$(MDEMODUNI)/StatusCode/Pei/PeiStatusCode.inf {
> - <BuildOptions>
> - MSFT:RELEASE_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib
> Gdi32.lib User32.lib Winmm.lib
> - DEBUG_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib
> Gdi32.lib User32.lib Winmm.lib
> - DEBUG_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib
> MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - RELEASE_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib
> MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - DEBUG_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib
> User32.lib Winmm.lib
> - RELEASE_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib
> Gdi32.lib User32.lib Winmm.lib
> -}
> -MdeModulePkg/Logo/Logo.inf
> -...
> -```
> diff --git a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> similarity index 94%
> rename from 3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> rename to 3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> index 6020c5c..504fa9f 100644
> --- a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.12 [UserExtensions] Sections
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.12 [UserExtensions] Sections
> +## 3.11 [UserExtensions] Sections
>
> The `[UserExtensions]` sections are optional.
>
> #### Summary
>
> diff --git a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> similarity index 93%
> rename from 3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> rename to 3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> index 23dec7d..dfa7fa8 100644
> --- a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> +++ b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.13 [DefaultStores] Section
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.13 [DefaultStores] Section
> +## 3.12 [DefaultStores] Section
>
> The `[DefaultStores]` section is optional in all EDK II DSC files.
>
> #### Summary
>
> diff --git a/3_edk_ii_dsc_file_format/32_general_rules.md
> b/3_edk_ii_dsc_file_format/32_general_rules.md
> index e040abc..d0cdb9b 100644
> --- a/3_edk_ii_dsc_file_format/32_general_rules.md
> +++ b/3_edk_ii_dsc_file_format/32_general_rules.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.2 General Rules
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -118,16 +118,5 @@ is unknown.
>
> Unless otherwise noted, all file names and paths are relative EDK II Packages
> (subdirectories in directories pointed to by WORKSPACE or PACKAGES_PATH
> system
> environment variables). A directory name that starts with a word is assumed
> by
> the build tools to be an EDK II Package directory name.
> -
> -Each module may have one or more INF files that can be used by tools to
> -generate images. Specifically, the EDK Compatibility Package may contain
> two
> -INF files for any module that contains assembly code. Since the ECP can be
> used
> -with existing EDK tools (which is only supported by Microsoft and Intel
> Windows
> -based tools,) a separate INF file to support the multiple tool chain capability
> -of the EDK II build system must be provided for the modules that contain
> -assembly code. The EDK II ECP will use the _basename_edk2.inf_ for the
> filename
> -of the EDK II build system compatible INF files for non-Windows based tool
> -chains, and use just the _basename.inf_ for the filename of EDK only INF
> files
> -used by the EDK build system.
> diff --git a/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> index 07f10d6..0679ff0 100644
> --- a/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> +++ b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.3 Platform DSC Definition
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -45,24 +45,21 @@ PatchableInModule or DynamicEx PCDs.
> specified in the `[Defines]` section or SET statements.
> **********
>
> The `[Defines]` section must appear before any other sections (except the
> header comment blocks). The remaining sections may appear in any order,
> however
> -the EBNF, below, shows the recommended order. (The `[Libraries]` section
> is
> -required if building EDK libraries and components in the context of an EDK II
> -platform.)
> +the EBNF, below, shows the recommended order.
>
> #### Summary
>
> The EDK II Platform Description (DSC) file has the following format (using the
> EBNF).
>
> ```c
> <EDK_II_DSC> ::= [<Header>]
> <Defines>
> [<SkuIds>]
> - <Libraries>*
> <LibraryClasses>*
> <Pcds>*
> <Components>+
> <BuildOptions>*
> <UserExtensions>*
> @@ -377,12 +374,11 @@ Highest Priority
> 3. Macros defined in the DSC file's `[Defines]` section
>
> Lowest Priority
>
> Macros defined in the `[Defines]` section are considered global during the
> -processing of the FDF file and the DSC file. `EDK_GLOBAL` macros are
> considered
> -global during the processing of DSC, FDF and EDK INF files.
> +processing of the FDF file and the DSC file.
>
> Macros are not allowed to redefine the reserved words specified in this file.
> For example, it is not permitted to `DEFINE DEFINE = FOOBAR`, then use
> `FOOBAR`
> as a the reserved word.
>
> @@ -406,13 +402,12 @@ may report the error on the line that uses the
> macro, `$(MACRO)`, rather than
> where the macro was defined.
>
> #### Prototype
>
> ```c
> -<MacroDefinition> ::= {<NormalMacro>} {<EdkMacro>}
> +<MacroDefinition> ::= {<NormalMacro>}
> <NormalMacro> ::= <TS> "DEFINE" <MTS> <MACRO> <Eq> [<Value>]
> <EOL>
> -<EdkMacro> ::= <TS> "EDK_GLOBAL" <MTS> <MACRO> <Eq> [<Value>]
> <EOL>
> <Value> ::= {<Number>} {<BoolType>} {<GUID>}
> {<CString>} {<UnicodeString>} {<CArray>}
> {<PATH>} {<Expression>} {<CFlags>}
> {<RelativePath>} {<Filename>}
> ```
> @@ -449,11 +444,10 @@ defined in this file may be used in the Flash FDF file.
>
> ```
> DEFINE GEN_SKU = MyPlatformPkg/GenPei
> DEFINE SKU1 = MyPlatformPkg/Sku1/Pei
> DEFINE HACK = DEBUG
> -EDK_GLOBAL EFI_ACPI_TABLE_STORAGE_GUID = 7E374E25-8E01-4FEE-
> 87F2390C23C606CD
> ```
>
> ### 3.3.3 Conditional Directive Blocks
>
> Use of conditional directive blocks is optional.
> @@ -697,12 +691,11 @@ in the DSC file. The included file's content must
> match the content of the
> section that the `!include` statement resides, or it may contain completely
> new
> sections. If the included file starts with a section header, then the section
> being processed in the Platform DSC file is considered to have been
> terminated.
>
> If the `<Filename>` contains "$" characters, then macros defined in the DSC
> -file and the system environment variables, `$(WORKSPACE)`,
> `$(EDK_SOURCE)`,
> -`$(EFI_SOURCE)`, and `$(ECP_SOURCE)` are substituted into `<Filename>`.
> +file and the system environment variable `$(WORKSPACE)` are substituted
> into `<Filename>`.
>
> The tools look for `<Filename>` relative to the directory the DSC file resides.
> If the file is not found, and a directory separator is in `<Filename>`, the
> tools attempt to find the file in a WORKSPACE (or a directory listed in the
> PACKAGES_PATH) relative path. If the file cannot be found, the build system
> diff --git a/3_edk_ii_dsc_file_format/35_[defines]_section.md
> b/3_edk_ii_dsc_file_format/35_[defines]_section.md
> index 7337415..ea2077d 100644
> --- a/3_edk_ii_dsc_file_format/35_[defines]_section.md
> +++ b/3_edk_ii_dsc_file_format/35_[defines]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.5 [Defines] Section
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -179,19 +179,10 @@ specifying the three language codes in this
> statement will limit the final
> output of string parsing tools to strings for these three languages. Tools must
> use a "Get Best Language" function when filtering the content. The
> `RFC_LANGUAGES` statement must be used when processing EDK II
> Modules. Space
> characters are not permitted within the list.
>
> -**_ISO 639-2 Language Code_**
> -
> -One or more three character language codes, formatted per ISO 639-2, with
> no
> -separator character (for example: "engfraspa".) This list can be used to filter
> -the output of tools that generate unicode strings. Tools must use a "Get
> Best
> -Language" function when filtering the content. The `ISO_LANGUAGES`
> statement
> -must be used when processing EDK Components. Space characters are not
> permitted
> -within the list.
> -
> **_BuildNumber_**
>
> This value, if present, will be used during the creation of
> `EFI_SECTION_VERSION` sections. Values in this file override any values set
> in
> the INF files. If not present, the EDK II build tools must use a value of `0`.
> @@ -225,8 +216,7 @@ compiling them into a machine language program.
> OUTPUT_DIRECTORY = Build/Nt32
> SUPPORTED_ARCHITECTURES = IA32
> BUILD_TARGETS = DEBUG|RELEASE
> RFC_LANGUAGES = "en-us;
> zh-hans;fr-fr"
> - ISO_LANGUAGES = "engchnfra"
> SKUID_IDENTIFIER = SkuTwo|DEFAULT
> ```
> diff --git a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> index 71d778d..5f0a95c 100644
> --- a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.6 [BuildOptions] Sections
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -49,16 +49,15 @@ expectation is that other tools will be responsible for
> expanding the macro.
> This section is used to replace flags or append flags to the end of the tool
> code flags defined in the `tools_def.txt` file. The `Family` tag can be used
> for elements that are shared between different architectures, and different
> tool chain tag names.
>
> -The `[BuildOptions]` section modifier, CodeBase, (value of EDK or EDKII,
> -default is EDKII) allows for platform integrators to override default build
> +The `[BuildOptions]` section modifier, CodeBase, (value is EDKII) allows for
> +platform integrators to override default build
> options set in the `tools_def.txt` file scoped according to the type of INF
> file being processed. EDK II INF files all contain an `INF_VERSION` element in
> -their `[Defines]` section, while EDK libraries and components do not have
> the
> -element. The `[BuildOptions]` section of an INF file override both the
> +their `[Defines]` section. The `[BuildOptions]` section of an INF file override
> both the
> `tools_def.txt` options and the options set in the `[BuildOptions]` section. In
> order to override options set in the INF file, the options must be overridden
> using the INF scoped `<BuildOptions>` tag after an INF file specified in the
> `[Components]` section.
>
> @@ -167,27 +166,27 @@ The result would logically be: `*_*_*_TEST_FLAGS
> = /a /b`
> ```
>
> The result for EDK II modules would be: `*_*_*_TEST_FLAGS = /a /b /c`
>
> ```ini
> -[BuildOptions.common.EDK]
> - # Entries are for EDK components and libraries
> +[BuildOptions.common.EDKII]
> + # Entries are for EDK II components and libraries
> *_*_*_TEST_FLAGS = /d
> ```
>
> -The result for EDK components and libraries would be: `*_*_*_TEST_FLAGS
> = /a /b /d`
> +The result for EDKII components and libraries would be:
> `*_*_*_TEST_FLAGS = /a /b /d`
>
> ```ini
> [BuildOptions.IA32]
> # Architectural options for IA32
> *_*_*_TEST_FLAGS = /e
> ```
>
> The logical result is: `*_*_IA32_TEST_FLAGS = /a /b /c /e`
>
> ```ini
> -[BuildOptions.X64.EDK]
> +[BuildOptions.X64.EDKII]
> # Architectural options for X64
> *_*_*_TEST_FLAGS = /f
> DEBUG_*_*_TEST_FLAGS = /g
> RELEASE_*_*_TEST_FLAGS = /h
> ```
> @@ -220,11 +219,11 @@ The logical result is:
> #### Prototype
>
> ```c
> <BuildOptions> ::= "[BuildOptions" [<attribs>] "]" <EOL> <Statements>*
> <attribs> ::= "." <arch> [<CodeBase> ["." <ModuleType>]]
> -<CodeBase> ::= "." {"Common"} {"EDK"} {"EDKII"}
> +<CodeBase> ::= "." {"Common"} {"EDKII"}
> <Statements> ::= {<MacroDefinition>} {<IncludeStatement>}
> {<TS> <BStatement>}
> <BStatement> ::= {<ToolFlag>} {<ToolPath>} {<ToolCmd>} {<Other>}
> <ToolFlag> ::= [<Family> ":"] <FlagSpec> <Equal> <Flags> <EOL>
> <ToolPath> ::= [<Family> ":"] <PathSpec> <Equal> <PATH> <EOL>
> diff --git a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> b/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> deleted file mode 100644
> index 23c441c..0000000
> --- a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> +++ /dev/null
> @@ -1,94 +0,0 @@
> -<!--- @file
> - 3.8 [Libraries] Sections
> -
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> -
> - Redistribution and use in source (original document form) and 'compiled'
> - forms (converted to PDF, epub, HTML and other formats) with or without
> - modification, are permitted provided that the following conditions are met:
> -
> - 1) Redistributions of source code (original document form) must retain the
> - above copyright notice, this list of conditions and the following
> - disclaimer as the first lines of this file unmodified.
> -
> - 2) Redistributions in compiled form (transformed to other DTDs, converted
> to
> - PDF, epub, HTML and other formats) must reproduce the above copyright
> - notice, this list of conditions and the following disclaimer in the
> - documentation and/or other materials provided with the distribution.
> -
> - THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND
> ANY EXPRESS OR
> - IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES OF
> - MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED. IN NO
> - EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT LIMITED TO,
> - PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
> OR PROFITS;
> - OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> LIABILITY,
> - WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> NEGLIGENCE OR
> - OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> - ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> -
> --->
> -
> -## 3.8 [Libraries] Sections
> -
> -The section `[Libraries]` sections are optional in EDK II DSC files, although
> -if any EDK component is specified in the `[Components]` section, then the
> EDK
> -II DSC file must contain this section. EDK components can not use EDK II
> -Library Instances.
> -
> -#### Summary
> -
> -Defines the `[Libraries]` section tag which lists the libraries that are linked
> -against
> -
> -EDK I components. Entries may appear in any order. Entries for EDK are a list
> -of INF files, with a path that is relative to the `$(EFI_SOURCE)`,
> -`$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories (or a MACRO definition).
> -
> -One or more `!include` statements may be used within the libraries sections.
> If
> -used, the file included must be a list of INF files and their paths relative to
> -the `$(EFI_SOURCE)`, `$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories.
> -
> -#### Prototype
> -
> -```c
> -<Libraries> ::= "[Libraries" [<attribs>] "]" <EOL> <LibStatements>*
> -<LibStatements> ::= {<MacroDefinition>} {<IncludeStatement>}
> - {<Statement>}
> -<attribs> ::= "." <arch> [", Libraries." <arch>]*
> -<Statement> ::= <TS> <PathAndFilename> <EOL>
> -<PathAndFilename> ::= <LPATH> <Word> ".inf"
> -<LPATH> ::= [{"$(EDK_SOURCE)"} {<MACROVAL>} "/"] <Path>*
> -<Path> ::= <Word> "/"
> -```
> -
> -#### Parameters
> -
> -**_arch_**
> -
> -The arch attribute must be specified in the `Conf/tools_def.txt` file for the
> -tool chain used to build the platform in order to be valid.
> -
> -**_Path_**
> -
> -If only the `<Path>` element is specified, the path is `WORKSPACE` relative.
> -
> -#### Example
> -
> -```ini
> -[Libraries]
> - Foundation/Efi/Guid/EfiGuidLib.inf
> - Foundation/Framework/Guid/EdkFrameworkGuidLib.inf
> - Foundation/Guid/EdkGuidLib.inf
> - Foundation/Library/EfiCommonLib/EfiCommonLib.inf
> - Foundation/Cpu/Pentium/CpuIA32Lib/CpuIA32Lib.inf
> - Foundation/Cpu/Itanium/CpuIA64Lib/CpuIA64Lib.inf
> - Foundation/Library/CustomizedDecompress/CustomizedDecompress.inf
> -
> -[Libraries.IA32]
> - DEFINE PLATFORM_DIR = $(EDK_SOURCE)/Platform
> - $(PLATFORM_DIR)/IntelEpg/Guid/IntelEpgGuidLib.inf
> - $(PLATFORM_DIR)/IntelEpg/Ppi/IntelEpgPpiLib.inf
> - $(PLATFORM_DIR)/Generic/Guid/GenericGuidLib.inf
> - $(PLATFORM_DIR)/Generic/Lib/Port80MappingLib/PlatformPort80.inf
> -```
> diff --git a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> similarity index 95%
> rename from 3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> rename to 3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> index 9ac3878..cc9f96e 100644
> --- a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> +++ b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.9 [LibraryClasses] Sections
>
> - Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.9 [LibraryClasses] Sections
> +## 3.8 [LibraryClasses] Sections
>
> The `[LibraryClasses]` sections are optional if no library classes are defined
> for any of the components, or if only EDK modules are used.
>
> #### Summary
> diff --git a/3_edk_ii_dsc_file_format/310_pcd_sections.md
> b/3_edk_ii_dsc_file_format/39_pcd_sections.md
> similarity index 97%
> rename from 3_edk_ii_dsc_file_format/310_pcd_sections.md
> rename to 3_edk_ii_dsc_file_format/39_pcd_sections.md
> index f982d60..96e4f0e 100644
> --- a/3_edk_ii_dsc_file_format/310_pcd_sections.md
> +++ b/3_edk_ii_dsc_file_format/39_pcd_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.10 PCD Sections
>
> - Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
>
> Redistribution and use in source (original document form) and 'compiled'
> forms (converted to PDF, epub, HTML and other formats) with or without
> modification, are permitted provided that the following conditions are met:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.10 PCD Sections
> +## 3.9 PCD Sections
>
> The PCD sections are optional.
>
> PCD Values listed in the DSC file must be absolute values, macro names or
> expressions which may include other PCD names and/or macro names that
> have been
> @@ -111,11 +111,11 @@ PCDs with a C strucutre type is also a VOID* PCD. Its
> value can be specified lik
> normal VOID* PCD, and also be specified by its structure field.
>
> Refer to the _EDK II Build Specification_ for the description of the PCD
> processing rules.
>
> -### 3.10.1 [PcdsFeatureFlag] Sections
> +### 3.9.1 [PcdsFeatureFlag] Sections
>
> These are optional sections for EDK II DSC Files.
>
> #### Summary
>
> @@ -192,11 +192,11 @@ section tag can only be used as a conditional
> modifier.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.2 [PcdsFixedAtBuild] Section
> +### 3.9.2 [PcdsFixedAtBuild] Section
>
> These are optional sections for EDK II DSC Files.
>
> #### Summary
>
> @@ -298,11 +298,11 @@ must be used.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.3 [PcdsPatchableInModule] Sections
> +### 3.9.3 [PcdsPatchableInModule] Sections
>
> These are optional sections.
>
> #### Summary
>
> @@ -403,11 +403,11 @@ must be used.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.4 [PcdsDynamic] Sections
> +### 3.9.4 [PcdsDynamic] Sections
>
> These are optional sections.
>
> #### Summary
>
> @@ -632,11 +632,11 @@ the _UEFI Specification_ for a description of these
> attributes.
> [PcdsDynamicHii.IA32, PcdsDynamicHii.X64.Sku1.Standard]
>
> gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|L"TestVariable"|gSy
> sConfigGuid|0x83|0x0
>
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L
> "Timeout"|gEfiGlobalVariableGuid|0x0|10 # Variable: L"Timeout"
> ```
>
> -### 3.10.5 [PcdsDynamicEx] Sections
> +### 3.9.5 [PcdsDynamicEx] Sections
>
> These are optional sections.
>
> #### Summary
>
> --
> 2.20.1.windows.1
next prev parent reply other threads:[~2019-03-05 15:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 3:48 [Patch] Document: Update DSC spec to remove EDK related contents Feng, Bob C
2019-03-05 15:24 ` Carsey, Jaben [this message]
2019-03-06 8:31 ` Gao, Liming
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=CB6E33457884FA40993F35157061515CBCB9417C@FMSMSX103.amr.corp.intel.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