From: "Feng, Bob C" <bob.c.feng@intel.com>
To: edk2-devel@lists.01.org
Cc: Bob Feng <bob.c.feng@intel.com>,
Liming Gao <liming.gao@intel.com>,
Jaben Carsey <jaben.carsey@intel.com>
Subject: [Patch] Document: Update Inf spec to remove EDK related contents
Date: Mon, 4 Mar 2019 21:52:05 +0800 [thread overview]
Message-ID: <20190304135205.3616-1-bob.c.feng@intel.com> (raw)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
Remove EDK related contents
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 | 2 +-
2_inf_overview/210_[ppis]_section.md | 1 -
2_inf_overview/211_[guids]_section.md | 1 -
.../212_[libraryclasses]_section.md | 1 -
2_inf_overview/213_[packages]_section.md | 1 -
2_inf_overview/214_pcd_sections.md | 14 +-
2_inf_overview/215_[depex]_section.md | 4 -
2_inf_overview/21_processing_overview.md | 19 +-
.../22_information_file_general_rules.md | 30 +-
2_inf_overview/24_[defines]_section.md | 4 +-
2_inf_overview/25_[sources]_section.md | 4 -
2_inf_overview/26_[buildoptions]_section.md | 9 +-
2_inf_overview/27_[binaries]_section.md | 5 -
2_inf_overview/29_[protocols]_section.md | 1 -
2_inf_overview/README.md | 11 -
.../314_[depex]_sections.md | 6 +-
.../315_[binaries]_section.md | 5 -
.../32_component_inf_definition.md | 4 +-
.../34_[defines]_section.md | 6 +-
.../35_[buildoptions]_sections.md | 5 +-
.../39_[sources]_sections.md | 7 +-
3_edk_ii_inf_file_format/README.md | 4 -
...ndix_a_build_changes_and_customizations.md | 0
.../README.md | 40 --
.../a1_design_discussion.md | 317 ------------
.../a2_edk_file_specification.md | 461 ------------------
...ndix_c_symbols.md => appendix_b_symbols.md | 0
...d => appendix_c_sample_driver_inf_files.md | 0
... => appendix_d_sample_library_inf_files.md | 0
...d => appendix_e_sample_binary_inf_files.md | 0
...ule_types.md => appendix_f_module_types.md | 0
31 files changed, 30 insertions(+), 932 deletions(-)
rename appendix_b_build_changes_and_customizations.md => appendix_a_build_changes_and_customizations.md (100%)
delete mode 100644 appendix_a_edk_inf_file_specification/README.md
delete mode 100644 appendix_a_edk_inf_file_specification/a1_design_discussion.md
delete mode 100644 appendix_a_edk_inf_file_specification/a2_edk_file_specification.md
rename appendix_c_symbols.md => appendix_b_symbols.md (100%)
rename appendix_d_sample_driver_inf_files.md => appendix_c_sample_driver_inf_files.md (100%)
rename appendix_e_sample_library_inf_files.md => appendix_d_sample_library_inf_files.md (100%)
rename appendix_f_sample_binary_inf_files.md => appendix_e_sample_binary_inf_files.md (100%)
rename appendix_g_module_types.md => appendix_f_module_types.md (100%)
diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index 9239080..7349614 100644
--- a/1_introduction/11_overview.md
+++ b/1_introduction/11_overview.md
@@ -40,11 +40,11 @@ Backward compatibility with the existing INF file formats. Changes made to this
specification must not require changes to existing INF files.
**Simplified platform build and configuration**
Simplify the build setup and configuration for a given platform. The process of
-adding EDK and EDK II firmware components to a firmware volume on any given
+adding EDK II firmware components to a firmware volume on any given
platform was also simplified.
**Distributing Modules**
Enable easy distribution of modules, both in source and binary form. Individual
diff --git a/2_inf_overview/210_[ppis]_section.md b/2_inf_overview/210_[ppis]_section.md
index bbdd2a4..1ab84eb 100644
--- a/2_inf_overview/210_[ppis]_section.md
+++ b/2_inf_overview/210_[ppis]_section.md
@@ -46,11 +46,10 @@ This section uses one of the following section definitions:
```ini
[Ppis]
[Ppis.common]
[Ppis.IA32]
[Ppis.X64]
-[Ppis.IPF]
[Ppis.EBC]
```
The formats for entries in this section is:
diff --git a/2_inf_overview/211_[guids]_section.md b/2_inf_overview/211_[guids]_section.md
index 7f53f6c..4176310 100644
--- a/2_inf_overview/211_[guids]_section.md
+++ b/2_inf_overview/211_[guids]_section.md
@@ -46,11 +46,10 @@ This section uses one of the following section definitions:
```ini
[Guids]
[Guids.common]
[Guids.IA32]
[Guids.X64]
-[Guids.IPF]
[Guids.EBC]
```
The formats for entries in this section is:
diff --git a/2_inf_overview/212_[libraryclasses]_section.md b/2_inf_overview/212_[libraryclasses]_section.md
index 8d2fd06..8a77463 100644
--- a/2_inf_overview/212_[libraryclasses]_section.md
+++ b/2_inf_overview/212_[libraryclasses]_section.md
@@ -46,11 +46,10 @@ This section uses one of the following section definitions:
```ini
[LibraryClasses]
[LibraryClasses.common]
[LibraryClasses.IA32]
[LibraryClasses.X64]
-[LibraryClasses.IPF]
[LibraryClasses.EBC]
```
The format for entries in this section is:
diff --git a/2_inf_overview/213_[packages]_section.md b/2_inf_overview/213_[packages]_section.md
index 81a49a8..f534967 100644
--- a/2_inf_overview/213_[packages]_section.md
+++ b/2_inf_overview/213_[packages]_section.md
@@ -47,11 +47,10 @@ This section uses one of the following section definitions:
```ini
[Packages]
[Packages.common]
[Packages.IA32]
[Packages.X64]
-[Packages.IPF]
[Packages.EBC]
```
The path must include the DEC file name and the name of the directory that
contains the DEC file.
diff --git a/2_inf_overview/214_pcd_sections.md b/2_inf_overview/214_pcd_sections.md
index 80a8be5..2fafa24 100644
--- a/2_inf_overview/214_pcd_sections.md
+++ b/2_inf_overview/214_pcd_sections.md
@@ -29,13 +29,13 @@
-->
## 2.14 PCD Sections
-These sections are used for specifying PCD information and are valid for EDK
-II modules only. The entries for these sections are looked up from the package
-declaration files (DEC) for generating the `AutoGen.c` and `AutoGen.h` files.
+These sections are used for specifying PCD information. The entries for these
+sections are looked up from the packagedeclaration files (DEC) for generating
+the `AutoGen.c` and `AutoGen.h` files.
The PCD's Name (`PcdName`) is defined as PCD Token Space GUID C name and the
PCD C name - separated by a period "." character. Unique PCDs are identified
using the following format to identify the named PCD:
@@ -43,11 +43,11 @@ using the following format to identify the named PCD:
PCDs listed in architectural sections must not be listed in common
architectural sections. It is not possible for a PCD to be valid for only IA32
and also valid for any architecture.
-A PCD may be valid for IA32 and X64 and invalid for EBC and IPF usage, so
+A PCD may be valid for IA32 and X64 and invalid for EBC usage, so
mixing of specific architectural modifiers is permitted.
This section defines how a module has been coded to access a PCD. A PCD can
only be accessed using the function defined by the UEFI specification for a
single type, therefore, mixing PCD section types is not permitted.
@@ -90,11 +90,10 @@ one of the following section definitions:
```ini
[(PcdType)]
[(PcdType).common]
[(PcdType).IA32]
[(PcdType).X64]
-[(PcdType).IPF]
[(PcdType).EBC]
```
The required entries for this section are the PCD Token Space Guid C Name's for
the PCD that will be looked up by tools from the DEC files, and the PCD's C
@@ -141,11 +140,10 @@ definitions:
```ini
[FixedPcd]
[FixedPcd.common]
[FixedPcd.IA32]
[FixedPcd.X64]
-[FixedPcd.IPF]
[FixedPcd.EBC]
```
The following is an example of the `PCD FIXED_AT_BUILD` type:
@@ -167,11 +165,10 @@ character. This section uses one of the following section definitions:
```ini
[PatchPcd]
[PatchPcd.IA32]
[PatchPcd.X64]
-[PatchPcd.IPF]
[PatchPcd.EBC]
[PatchPcd.common]
```
The following is an example of the `PCD FIXED_AT_BUILD` type:
@@ -193,11 +190,10 @@ binary only module. This section uses one of the following section definitions:
```ini
[FeaturePcd]
[FeaturePcd.common]
[FeaturePcd.IA32]
[FeaturePcd.X64]
-[FeaturePcd.IPF]
[FeaturePcd.EBC]
```
The following is an example of the PCD `FEATURE_FLAG` type:
@@ -221,11 +217,10 @@ following section definitions:
```ini
[Pcd]
[Pcd.common]
[Pcd.IA32]
[Pcd.X64]
-[Pcd.IPF]
[Pcd.EBC]
```
The following is an example of the PCD `DYNAMIC` type:
@@ -247,11 +242,10 @@ format. This section uses one of the following section definitions:
```ini
[PcdEx]
[PcdEx.common]
[PcdEx.IA32]
[PcdEx.X64]
-[PcdEx.IPF]
[PcdEx.EBC]
```
The following is an example of the PCD `DYNAMIC_EX` type:
diff --git a/2_inf_overview/215_[depex]_section.md b/2_inf_overview/215_[depex]_section.md
index 5c1f110..09fc74c 100644
--- a/2_inf_overview/215_[depex]_section.md
+++ b/2_inf_overview/215_[depex]_section.md
@@ -29,13 +29,10 @@
-->
## 2.15 [Depex] Section
-The EDK II `[Depex]` section is a replacement for the `DPX_SOURCE` file using
-in EDK (the file is specified in the nmake section of an EDK INF file.)
-
This section is used for specifying a `Depex` expression, not a binary file. In
the "As Built" INF files, this section contains a comment that lists the full
dependency expression, including `Depex` statements AND'd from library
instances linked against a module.
@@ -87,11 +84,10 @@ The Depex section headers start with one of the following:
```ini
[Depex]
[Depex.IA32]
[Depex.X64]
-[Depex.IPF]
[Depex.EBC]
[Depex.common]
```
When generating the "As Built" binary INF during a build, the complete
diff --git a/2_inf_overview/21_processing_overview.md b/2_inf_overview/21_processing_overview.md
index 440d5d9..cbdfe22 100644
--- a/2_inf_overview/21_processing_overview.md
+++ b/2_inf_overview/21_processing_overview.md
@@ -34,23 +34,12 @@
Each module or component INF file is broken out into sections in a manner
similar to the other build meta-data files. However, the intent of a module's
INF file is to define the source files, libraries, and definitions relevant to
building the module, creating binary files that are either raw binary files or
PE32/PE32+/coff format files. The different sections are described in detail in
-this chapter. In general, the original EDK parsing utilities read each line
-from the `[Libraries]` or `[Components]` sections of the build description
-(DSC) file, process the INF file on a line to generate a makefile, and then
-continued with the next line. EDK II parsing utilities are token based, which
-permits an element to span multiple lines. The EDK II utilities check both EDK
-and EDK II INF files, and, if required, generate C code files based on the
-content of the EDK II INF. Refer to the _EDK II Build Specification_ for more
-information regarding these autogenerated files.
-
-One major difference between EDK and EDK II is support for non-Microsoft
-development environments. Because modules may be distributed to developers that
-use these environments, both source code and the meta-data files need to be
-UNIX*/ GCC clean. One little known fact regarding the Microsoft tools and
-operating systems is their ability to process the forward slash "/" character
-as a directory separator.
+this chapter. EDK II parsing utilities are token based, which permits an element
+to span multiple lines. The EDK II utilities check EDK II INF files, and, if required,
+generate C code files based on the content of the EDK II INF. Refer to
+the _EDK II Build Specification_ for more information regarding these autogenerated files.
All EDK II INF files MUST use this forward slash character for all directory
paths specified.
diff --git a/2_inf_overview/22_information_file_general_rules.md b/2_inf_overview/22_information_file_general_rules.md
index 4741917..fd4bbdc 100644
--- a/2_inf_overview/22_information_file_general_rules.md
+++ b/2_inf_overview/22_information_file_general_rules.md
@@ -29,22 +29,18 @@
-->
## 2.2 Information File General Rules
-This section covers the format for the EDK II module INF files. While the EDK
-code base and tools treated libraries completely separate from modules, the EDK
-II code base and tools process modules, with libraries being considered a
+This section covers the format for the EDK II module INF files. The EDK
+II code base and tools process modules, with libraries is considered a
module that produces a library class.
### 2.2.1 Section Entries
-To simplify parsing, the EDK II meta-data files continue using the INI format.
-This style was introduced for EDK meta-data files, when only the Windows tool
-chains were supported. It was decided that for compatibility purposes, that INI
-format would continue to be used. EDK II formats differ from the defacto format
-in that the semicolon ";" character cannot be used to indicate a comment.
+The EDK II meta-data files use the INI format. The semicolon ";" character cannot
+be used to indicate a comment in the EDK II format.
Leading and trailing space/tab characters must be ignored.
Duplicate section names must be merged by tools.
@@ -52,11 +48,11 @@ This description file consists of sections delineated by section tags enclosed
within square `[]` brackets. Section tag entries are case-insensitive. The
different sections and their usage are described below. The text of a given
section can be used for multiple section names by separating the section names
with a comma. For example:
-`[Sources.X64, Sources.IPF]`
+`[Sources.X64, Sources.IA32]`
The content below each section heading is processed by the parsing utilities in
the order that they occur in the file. The precedence for processing these
architecture section tags is from right to left, with sections defining an
architecture having a higher precedence than a section which uses common (or no
@@ -184,14 +180,13 @@ case sensitive because of multiple environment support.
* All files (except those listed in the Packages sections) must reside in the
directory containing the INF file or in sub-directories of the directory
containing the INF file.
* Additionally, all EDK II directories that are architecturally dependent must
- use a name with only the first character capitalized. Ia32, Ipf, X64 and Ebc
- are valid architectural directory names. IA32, IPF and EBC are not acceptable
- directory names, and may cause build breaks. From a build tools perspective,
- IA32 is not equivalent to Ia32 or ia32.
+ use a name with only the first character capitalized. Ia32 is valid architectural
+ directory names. IA32 is not acceptable directory names, and may cause build
+ breaks. From a build tools perspective, IA32 is not equivalent to Ia32 or ia32.
* Absolute paths are not permitted in EDK II INF files. All paths specified are
relative to an EDK II package directory (defined as a directory containing a
DEC file) or relative to the directory containing the INF file.
@@ -207,14 +202,14 @@ places that permit the use of space characters in a directory path.
The EDK II Coding Style specification covers naming conventions for use within
C Code files, and as well as specifying the rules for directory and file names.
This section is meant to highlight those rules as they apply to the content of
the INF files.
-Architecture keywords (`IA32`, `IPF`, `X64` and `EBC`) are used by build tools
+Architecture keywords (`IA32`, `X64`, and `EBC`) are used by build tools
and in metadata files for describing alternate threads for processing of files.
These keywords must not be used for describing directory paths. Additionally,
-directory names with architectural names (Ia32, Ipf, X64 and Ebc) do not
+directory names with architectural names (Ia32, X64 and Ebc) do not
automatically cause the build tools or meta-data files to follow these
alternate paths. Directories and Architectural Keywords are similar in name
only.
All directory paths within EDK II INF files must use the forward slash "/"
@@ -313,15 +308,10 @@ evaluated, during the parsing of the file.
[LibraryClasses.X64.PEIM]
# Can use $(MDE) and $(PERF)
DEFINE MDEMEM = $(MDE)/PeiMemoryAllocationLib
MemoryAllocationLib|$(MDEMEM)/PeiMemoryAllocationLib.inf
-[LibraryClasses.IPF]
- # Cannot use $(PERF) or $(MDEMEM)
- # Can use $(MDE) from the common section
- PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
- TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
```
In the previous example, the directory and filename for a library instance is
the recommended instance and may not be the actual library linked to the
module, as the platform integrator may choose a different library instance to
diff --git a/2_inf_overview/24_[defines]_section.md b/2_inf_overview/24_[defines]_section.md
index 8e5706c..de605e5 100644
--- a/2_inf_overview/24_[defines]_section.md
+++ b/2_inf_overview/24_[defines]_section.md
@@ -107,18 +107,18 @@ dispatch instance.
**********
###### Table 1 EDK II [Defines] Section Elements
|Tag |Required |Value | Notes |
-|----------------------------|-------------------------------------------------------------|--------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------|
+|----------------------------|-------------------------------------------------------------|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|`INF_VERSION` |REQUIRED |1.27 or 0x0001001B | This identifies the INF spec version. It is decimal value with fraction or two-nibble hexadecimal representation of the same, for example: 1.27. Tools use this value to handle parsing of previous releases of the specification if there are incompatible changes. |
|`BASE_NAME` |REQUIRED |A single word | This is a single word identifier that will be used for the component name. |
|`PI_SPECIFICATION_VERSION` |Not required |Decimal or special format of hex| The minimum revision value across the module and all its dependent libraries. If a revision value is not declared in the module or any of the dependent libraries, then tools may use the value of 0, which disables checking. |
| | | | The `PI_SPECIFICATION_VERSION` must only be set in the INF file if the module depends on services or system table fields or PI core behaviors that are not present in the PI 1.0 version. For example, if a module depends on definitions in PI 1.1 that are not in PI 1.0, then `PI_SPECIFICATION_VERSION` must be 0x0001000A |
|`UEFI_SPECIFICATION_VERSION`|Not required |Decimal or special format of hex| The minimum revision value across the module and all its dependent libraries. If a revision value is not declared in the module or any of the dependent libraries, then tools may use the value of 0, which disables checking. |
| | | | The `UEFI_SPECIFICATION_VERSIon` must only be set in the INF file if the module depends on UEFI Boot Services or UEFI Runtime Services or UEFI System Table fields or UEFI core behaviors that are not present in the UEFI 2.1 version. For example, if a module depends on definitions in UEFI 2.2 that are not in UEFI 2.1, then `UEFI_SPECIFICATION_VERSION` must be 0x00020014 |
-|`FILE_GUID` |REQUIRED |GUID Value | Registry (8-4-4-4-12) Format. This value is required for all EDK II format INF files, required for EDK driver INF files, not required for EDK libraries |
+|`FILE_GUID` |REQUIRED |GUID Value | Registry (8-4-4-4-12) Format. This value is required for all EDK II format INF files. |
|`MODULE_TYPE` |REQUIRED | | This is the type of module. One of the EDK II Module Types. For Library Modules, the `MODULE_TYPE` must specify the `MODULE_TYPE` of the module that will typically use the library. |
|`BUILD_NUMBER` |Optional |UINT16 Value | This optional element, if present (or set in the DSC file), is used during the creation of the `EFI_VERSION_SECTION` for this module; if it is not present, then the BuildNumber field of the `EFI_VERSION_SECTION` will be set to 0. |
|`VERSION_STRING` |Optional |String | If present, this value will be encoded as USC-2 characters in a Unicode file for the VERSION section of the FFS unless a ver or ver_ui file has been specified in the `[Binaries]` section. |
|`MODULE_UNI_FILE` |Optional |Filename | A Unicode file containing UCS-2 character localization strings; the file path (if present) is relative to the directory containing the INF file. The use of #include statements in this file is prohibited. |
|`LIBRARY_CLASS` |Typically not specified for Driver; REQUIRED for Library only|Word | TypeList | One Library Class that is satisfied by this Library Instance; one or more `LIBRARY_CLASS` lines may be specified by a module. The reserved keyword, NULL, must be listed for library class instances that do NOT support a library class keyword. |
diff --git a/2_inf_overview/25_[sources]_section.md b/2_inf_overview/25_[sources]_section.md
index d98fd3f..899ef64 100644
--- a/2_inf_overview/25_[sources]_section.md
+++ b/2_inf_overview/25_[sources]_section.md
@@ -64,11 +64,10 @@ This section will typically use one of the following section definitions:
```ini
[Sources]
[Sources.common]
[Sources.IA32]
[Sources.X64]
-[Sources.IPF]
[Sources.EBC]
```
The formats for entries in this section are:
@@ -91,13 +90,10 @@ The following is an example for sources sections.
Ia32/DxeLoadFunc.c Ia32/ImageRead.c
[Sources.X64]
X64/DxeLoadFunc.c
-[Sources.IPF]
- Ipf/DxeLoadFunc.c
- Ipf/ImageRead.c
```
All Unicode files must be listed in the source section. If a Unicode file,
`A.uni`, has the statement: `#include B.uni`, and `B.uni` has a statement:
`#include C.uni`, both `B.uni` and `C.uni` files must be listed in the INF
diff --git a/2_inf_overview/26_[buildoptions]_section.md b/2_inf_overview/26_[buildoptions]_section.md
index ca29898..017b595 100644
--- a/2_inf_overview/26_[buildoptions]_section.md
+++ b/2_inf_overview/26_[buildoptions]_section.md
@@ -70,22 +70,15 @@ shown above.
|:-----------:|:----------:|:----------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `FAMILY` | NO | No | `Conf/tools_def.txt` defines the `FAMILY` values, for example: `MSFT`, `INTEL` or `GCC`. Typically, this field is used to help the build tools determine whether the line is used for Microsoft style Makefiles or the GNU style Makefiles. |
| | | | By not specifying the `FAMILY`, the tools assume the flags are applicable to all families. |
| `TARGET` | YES | Yes = * | `Conf/tools_def.txt` file defines two values: `DEBUG` and `RELEASE`. Developers may define additional targets. |
| `TAGNAME` | YES | Yes = * | `Conf/tools_def.txt` file defines several different tag names - these are defined by developers; the default tag name, `MYTOOLS`, is provided in the template for tools_def.txt and set in the `Conf/target.txt` file. |
-| `ARCH` | YES | Yes = * | `Conf/tools_def.txt` defines at least four architectures: `IA32`, `X64`, `IPF` and `EBC`. This tag must use all capital letters for the tag. Additional Architectures, such as PPC or ARM may be added as support becomes available. |
+| `ARCH` | YES | Yes = * | `Conf/tools_def.txt` defines at least four architectures: `IA32`, `X64` and `EBC`. This tag must use all capital letters for the tag. Additional Architectures, such as PPC or ARM may be added as support becomes available. |
| `TOOLCODE` | YES | NO | The tool code must be one of the defined tool codes in the `Conf/tools_def.txt` file. The flags defined in this section are appended to flags defined in the `tools_def.txt` file for individual tools. |
| | | | EXCEPTION: If the INF `MODULE_TYPE`, defined in the `[Defines]` section is `USER_DEFINED`, then the flags listed in this section are the only flags used for the TOOLCODE command specified in `Conf/ tools_def.txt`. |
| `ATTRIBUTE` | YES | NO | The attribute must be specific to the tool code and must be a valid attribute handled by the build system. |
-**********
-**Note:** Regarding the EDK and EDK II distinctions in the table: Many EDK INF
-files must be processed by the EDK II build system, but no EDK INF
-specification exists. Therefore, items of this kind are listed in Appendix A
-for completeness. This limits what can be in an EDK INF file as well.
-**********
-
Developers should use extreme caution when specifying items in this section.
The EDK II build is designed to support multiple compilers and tool chains,
expecting that code is written in ANSI C. If custom tool flags are required by
a module, developers must make sure that all consumers of the module are aware
of the specific tools and tag names required.
diff --git a/2_inf_overview/27_[binaries]_section.md b/2_inf_overview/27_[binaries]_section.md
index 993b836..c05db6b 100644
--- a/2_inf_overview/27_[binaries]_section.md
+++ b/2_inf_overview/27_[binaries]_section.md
@@ -63,11 +63,10 @@ This section uses one of the following section definitions:
```ini
[Binaries]
[Binaries.common]
[Binaries.IA32]
[Binaries.X64]
-[Binaries.IPF]
[Binaries.EBC]
```
The formats for entries in this section are:
@@ -193,10 +192,6 @@ The following are examples of different types of `[Binaries]` sections.
PE32|Ia32/RELEASE/DxeIpl.efi|RELEASE # MYTOOLS DISPOSABLE|Ia32/DEBUG/DxeIpl.pdb
[Binaries.X64]
DXE_DEPEX|X64/DxeIpl.dpx # MYTOOLS
PE32|X64/DxeIpl.efi # MYTOOLS
-
-[Binaries.IPF]
- DXE_DEPEX|IPF/DxeIpl.dpx # MYTOOLS
- PE32|Ipf/DxeIpl.efi # MYTOOLS
```
diff --git a/2_inf_overview/29_[protocols]_section.md b/2_inf_overview/29_[protocols]_section.md
index 346e332..c7ade47 100644
--- a/2_inf_overview/29_[protocols]_section.md
+++ b/2_inf_overview/29_[protocols]_section.md
@@ -46,11 +46,10 @@ This section uses one of the following section definitions:
```ini
[Protocols]
[Protocols.common]
[Protocols.IA32]
[Protocols.X64]
-[Protocols.IPF]
[Protocols.EBC]
```
The formats for entries in this section is:
diff --git a/2_inf_overview/README.md b/2_inf_overview/README.md
index e78342a..a30f107 100644
--- a/2_inf_overview/README.md
+++ b/2_inf_overview/README.md
@@ -60,21 +60,10 @@ instances can "produce" the functionality of a library class. The use of
library class API headers allows for platform integrators to select a library
instance that is suitable for their platform. This usage model frees the driver
developer from coding a module to specific library instances. Libraries are
really nothing more than modules with pre-defined APIs.
-Each module may have one or more INF files that can be used by tools to
-generate images. Specifically, the EDK Compatibility Package will 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.
-
**********
**Note:** Path and Filename elements within the INF are case-sensitive in order
to support building on UNIX style operating systems.
**********
**Note:** GUID values are used during runtime to uniquely map the C names of
diff --git a/3_edk_ii_inf_file_format/314_[depex]_sections.md b/3_edk_ii_inf_file_format/314_[depex]_sections.md
index 3c0820a..7f90115 100644
--- a/3_edk_ii_inf_file_format/314_[depex]_sections.md
+++ b/3_edk_ii_inf_file_format/314_[depex]_sections.md
@@ -35,14 +35,12 @@ These are optional sections
#### Summary
Defines the optional EDK II INF file `[Depex]` section content. The `[Depex]`
section is a replacement for the dependency file specified by the driver
-writer. The `DPX_SOURCE` in the `[Defines]` section an EDK INF file will
-over-ride the dependency specified here. This section can be used for
-inheritance from libraries, by supporting logical AND'ing of the different
-Depex expressions together.
+writer. This section can be used for inheritance from libraries, by supporting
+logical AND'ing of the different Depex expressions together.
The Rules would be as follows:
* EDK II INF - `[Depex]` section and inheritance from libraries is supported
via AND'ing the different Depex expressions together
diff --git a/3_edk_ii_inf_file_format/315_[binaries]_section.md b/3_edk_ii_inf_file_format/315_[binaries]_section.md
index d6d57f2..9ddb8d0 100644
--- a/3_edk_ii_inf_file_format/315_[binaries]_section.md
+++ b/3_edk_ii_inf_file_format/315_[binaries]_section.md
@@ -185,11 +185,6 @@ PDB or SYMS files generated for symbolic debugging.
[Binaries.X64]
DXE_DEPEX|Debug/X64/DxeIpl.dpx # MYTOOLS
PE32|Debug/X64/DxeIpl.efi|DEBUG # MYTOOLS
DISPOSABLE|Debug/X64/DxeIpl.pdb|DEBUG
-
-[Binaries.IPF]
- DXE_DEPEX|Debug/IPF/DxeIpl.dpx # MYTOOLS
- PE32|Debug/Ipf/DxeIpl.efi|DEBUG # MYTOOLS
- DISPOSABLE|Debug/Ipf/DxeIpl.pdb|DEBUG
```
diff --git a/3_edk_ii_inf_file_format/32_component_inf_definition.md b/3_edk_ii_inf_file_format/32_component_inf_definition.md
index 7725ffe..aa06526 100644
--- a/3_edk_ii_inf_file_format/32_component_inf_definition.md
+++ b/3_edk_ii_inf_file_format/32_component_inf_definition.md
@@ -260,11 +260,11 @@ The following are common definitions used by multiple section types.
<ModuleTypeList> ::= <ModuleType> [" " <ModuleType>]*
<IdentifierName> ::= <TS> {<MACROVAL>} {<PcdName>} <TS>
<Boolean> ::= {<BoolType>} {<Expression>}
<EOL> ::= <TS> 0x0D 0x0A
<OA> ::= (a-zA-Z)(a-zA-Z0-9)*
-<arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {<OA>}
+<arch> ::= {"IA32"} {"X64"} {"EBC"} {<OA>}
<Edk2ModuleType> ::= {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"}
{"DXE_CORE"} {"DXE_DRIVER"}
{"DXE_SAL_DRIVER"}
{"DXE_RUNTIME_DRIVER"}
{"SMM_CORE"} {"DXE_SMM_DRIVER"}
@@ -322,11 +322,11 @@ must not be expanded by parsing tools.
**_OA_**
Other Architecture - One or more user defined target architectures, such as ARM
or PPC. The architectures listed here must have a corresponding entry in the
-EDK II meta-data file, `Conf/tools_def.txt`. Only IA32, X64, IPF and EBC are
+EDK II meta-data file, `Conf/tools_def.txt`. Only IA32, X64 and EBC are
routinely validated.
**_ExtendedLine_**
The use of the Extended Line format is prohibited.
diff --git a/3_edk_ii_inf_file_format/34_[defines]_section.md b/3_edk_ii_inf_file_format/34_[defines]_section.md
index 394db53..561abaf 100644
--- a/3_edk_ii_inf_file_format/34_[defines]_section.md
+++ b/3_edk_ii_inf_file_format/34_[defines]_section.md
@@ -62,22 +62,18 @@ HexVersion type, where the 0x0001 is the major number, and the 001B is the
minor number. This version of the specification provides full backward
compatibility to all previous versions. This means that tools that process
this version of the specification can also process earlier versions of
EDK II INF files.
-This version of the specification removes content in this section that was
-associated with EDK libraries and components. The section now lists only the
-defined EDK II symbols and format.
-
**********
**Note:** Possible values for `MODULE_TYPE`, and their descriptions, are
listed in the table, "EDK II Module Types." For each module, the `BASE_NAME`
and `MODULE_TYPE` are required. The `BASE_NAME` definition is case
sensitive as it will be used to create a directory name during a build.
**********
-Unlike EDK, only the `[Defines]` section tag is valid for EDK II INF files -
+Only the `[Defines]` section tag is valid for EDK II INF files -
architectural modifiers for the `[Defines]` section tag are not permitted. The
section is processed in order by the parsing utilities. Assignments of
variables in other sections override previous assignments.
The `SHADOW` keyword is only valid for `SEC`, `PEI_CORE` and `PEIM` module
diff --git a/3_edk_ii_inf_file_format/35_[buildoptions]_sections.md b/3_edk_ii_inf_file_format/35_[buildoptions]_sections.md
index 3a1bef9..aeaaf1e 100644
--- a/3_edk_ii_inf_file_format/35_[buildoptions]_sections.md
+++ b/3_edk_ii_inf_file_format/35_[buildoptions]_sections.md
@@ -123,11 +123,11 @@ other architecture type; doing so will result in a build break.
<Target> ::= {<Wildcard>} {Target}
<TagName> ::= {<Wildcard>} {TagName}
<CmdCode> ::= CommandCode
<CommandName> ::= CommandExecutable
<Attribute> ::= Attribute
-<tarch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {<OA>}
+<tarch> ::= {"IA32"} {"X64"} {"EBC"} {<OA>}
{<Wildcard>}
<CFlags> ::= (0x20 - 0x7e)+
<PathCmd> ::= <TOOLPATH> <FileSep> <CommandName>
<TOOLPATH> ::= {<PATH>} {<ABS_PATH> <PATH>}
<ABS_PATH> ::= {(a-zA-Z) ":\"} {"\"} {"/"}
@@ -179,11 +179,11 @@ A keyword that uniquely identifies the tool chain target architecture; the
third field. This flag is used to support the cross-compiler features, such as
when a development platform is IA32 and the target platform is X64 Using this
field, a single `TagName` can be setup to support building multiple target
platform architectures with different tool chains. As an example, if a
developer is using Visual Studio .NET 2003 for generating IA32 platform and
-uses the WINDDK version 3790.1830 for X64 or IPF platform images, a single tag
+uses the WINDDK version 3790.1830 for X64 platform images, a single tag
(see the MYTOOLS PATH settings in the generated `Conf/tools_def.txt` or
provided `BaseTools/Conf/tools_def.template` file.) The wildcard character,
"``*", is permitted if and only if the same tool is used for all target
architectures.
@@ -258,7 +258,6 @@ strings.
*_WINDDK3790x1830_*_CC_FLAGS = /Qwd1418,810
*_MYTOOLS_*_CC_FLAGS = /Qwd1418,810
*_VS2003_*_CC_FLAGS = /wd4244
*_WINDDK3790x1830_*_CC_FLAGS = /wd4244
*_MYTOOLS_*_CC_FLAGS = /wd4244
- RELEASE_MYTOOLS_IPF_ASM_FLAGS = = -N us -X explicit -M ilp64 - N so -W3 MSFT:*_*_*_*_FLAGS = /od $(MACRO)
```
diff --git a/3_edk_ii_inf_file_format/39_[sources]_sections.md b/3_edk_ii_inf_file_format/39_[sources]_sections.md
index 2383ad7..05d7b5d 100644
--- a/3_edk_ii_inf_file_format/39_[sources]_sections.md
+++ b/3_edk_ii_inf_file_format/39_[sources]_sections.md
@@ -48,18 +48,13 @@ filename is listed as myfile.c, the file must be located in the same directory
as the INF file. Absolute paths in the filename are prohibited.
There can be multiple sources sections, depending on the target processor.
Example sources sections are listed below. The parsing utility creates a
directory path for each file (`$(DEST_DIR)...\MyFile.c`), and looks up the
-makefile template for the `COMPONENT_TYPE` (EDK) or `MODULE_TYPE` (EDK II) to
+makefile template for the `MODULE_TYPE` (EDK II) to
emit.
-It is not permissible to mix EDK and EDK II style files within a module.
-
-The macro, `TABLE_NAME` may be used in existing EDK INF files that point to
-ACPI tables, this value will be ignored by EDK II build tools.
-
All HII Unicode format files must be listed in this section as well as any
other "source" type file, such as local module header files, Vfr files, etc.
Each source file must be listed only once per section. Files listed in
architectural sections are not permitted to be listed in the common
diff --git a/3_edk_ii_inf_file_format/README.md b/3_edk_ii_inf_file_format/README.md
index df55fac..15e1da1 100644
--- a/3_edk_ii_inf_file_format/README.md
+++ b/3_edk_ii_inf_file_format/README.md
@@ -32,9 +32,5 @@
# 3 EDK II INF File Format
This section of the document describes the EDK II INF sections using an
Extended Backus-Naur Form.
-**********
-**Note:** The elements of the EDK INF file (see Appendix A) and the EDK II INF
-files differ.
-**********
diff --git a/appendix_b_build_changes_and_customizations.md b/appendix_a_build_changes_and_customizations.md
similarity index 100%
rename from appendix_b_build_changes_and_customizations.md
rename to appendix_a_build_changes_and_customizations.md
diff --git a/appendix_a_edk_inf_file_specification/README.md b/appendix_a_edk_inf_file_specification/README.md
deleted file mode 100644
index a0af502..0000000
--- a/appendix_a_edk_inf_file_specification/README.md
+++ /dev/null
@@ -1,40 +0,0 @@
-<!--- @file
- Appendix A EDK INF File Specification
-
- Copyright (c) 2007-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.
-
--->
-
-# Appendix A EDK INF File Specification
-
-This appendix covers the format of the original EDK INF files. However, the
-format of comments in the EDK INF may vary from this specification, as the
-original EDK parsing tool, ProcessDSC, only looked for a specific set of
-tokens. Due the extensive use of MACRO statements in the EDK components and
-libraries INF files, EDK INF files cannot be processed by tools to create a
-distribution that complies with the UEFI Platform Initialization Distribution
-Package Specification.
diff --git a/appendix_a_edk_inf_file_specification/a1_design_discussion.md b/appendix_a_edk_inf_file_specification/a1_design_discussion.md
deleted file mode 100644
index 6c64df3..0000000
--- a/appendix_a_edk_inf_file_specification/a1_design_discussion.md
+++ /dev/null
@@ -1,317 +0,0 @@
-<!--- @file
- A.1 Design Discussion
-
- Copyright (c) 2007-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.
-
--->
-
-## A.1 Design Discussion
-
-Directive statements are permitted within the EDK INF files.
-
-### A.1.1 [defines] Section
-
-The `[defines]` section of an EDK INF file is used to define variable
-assignments that can be used in later build steps. The EDK parsing utilities
-process local symbol assignments made in this section. Note that the sections
-are processed in the order listed here, and later assignments of these local
-symbols do not override previous assignments.
-
-This section will typically use one of the following section definitions:
-
-```ini
-[define]
-[defines]
-[defines.IA32]
-[defines.X64]
-[defines.IPF]
-[defines.EBC]
-```
-
-**********
-**Note:** The `[define]` section tag is only valid for EDK INF files. EDK II INF
-files must use the 'defines' keyword.
-**********
-
-The format for entries in this section is:
-
-`Name = Value`
-
-The following is an example of this section.
-
-```ini
-[defines]
- BASE_NAME = DiskIo
- FILE_GUID = CA261A26-7718-4b9b-8A07-5178B1AE3A02
- COMPONENT_TYPE = BS_DRIVER
-```
-
-The following table lists the possible content of this section.
-
-###### Table 6 EDK [defines] Section Elements
-
-| Tag | Required | Value | Notes |
-| --------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `BASE_NAME` | Yes | A single word | This is a single word identifier that will be used for the component name. |
-| `COMPONENT_TYPE` | Yes | One of the EDK I Component Types | See Table EDK I Component (module) Types for possible values |
-| `FILE_GUID` | No--Optional for Libraries, Required for all other component types | Guid Value | Registry (8-4-4-4-12) Format GUID |
-| `EDK_RELEASE_VERSION` | No--Optional | Hex Value | A Hex version number, 0x00020000 |
-| `EFI_SPECIFICATION_VERSION` | No--Optional | HexValue | A Hex version number, 0x00020000 |
-| `MAKEFILE_NAME` | No--Optional | Filename.ext | The name of the Makefile to be generated for this component |
-| `CUSTOM_MAKEFILE` | No--Optional | Filename.ext | This specifies the name of a custom makefile that should be used, instead of a generated makefile. **NOTE**: EDK INF components specifying a custom EDK style makefile cannot be used in an EDK II build. |
-| `BUILD_NUMBER` | No--Optional | Set this four digit value in the generated Makefile | Normally not used in INF files. |
-| `C_FLAGS` | No--Optional | Microsoft C Flags to use with for a cl commands for this module | Normally not used in INF files. Typically, an EDK INF file will provide a separate nmake section to specify different build parameters. |
-| `FFS_EXT` | No--Optional | File Extension | The FFS extension to use for this component, refer to the table _EDK I Component (module) Types for the default FFS extension. This value is used to create a component PKG file. |
-| `FV_EXT` | No--Optional | File Extension | The FV extension to use for this component, refer to the table _EDK I Component (module) Types for the default FV extension. |
-| `SOURCE_FV` | No--Optional | Word | If present, the variable is set at the beginning of the generated makefile |
-| `VERSION` | No--Optional | Four digit integer | If present, this value will be used for the VERSION section of the FFS. |
-| `VERSION_STRING` | No--Optional | String | If present, this value will be used to generate the UNICODE file for the VERSION section of the FFS. |
-
-The following table lists the available `COMPONENT_TYPE` values supported by
-EDK INF files.
-
-###### Table 7 EDK Component (module) Output File Extensions
-
-| COMPONENT_TYPE | EDK II Extension | EDK File, FFS or FV Extension | Description |
-| ----------------------- | ---------------------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `LIBRARY` | .lib | .lib | Library component linked as part of the build with other components. |
-| `FILE` | From file name or .FFS | From file name or .FFS | Raw file copied directly to FV |
-| `Apriori` | .bin | .SEC | This EDK INF component is not supported in the EDK II build - it is created from content in other EDK II build meta-data files. |
-| `EFI Binary Executable` | .efi | .pe32 | PE32/PE32+/Coff binary executable. The extension of the file has changed for EDK II builds which generate processed (GenFw) images. |
-| `AcpiTable` | .acpi | .SEC | An ACPI Table. |
-| `Legacy16` | .bin | .SEC | The MODULE_TYPE for a Legacy16 when migrating to EDK II should be specified as USER_DEFIND. The .rom or .bin file should be included under a [binaries] section. In EDK, the COMPONENT_TYPE of Legacy16 was mostly used to specify PCI Option ROMs. |
-| `BINARY` | .bin | .FFS | |
-| `CONFIG` | .bin | .SEC | |
-| `LOGO` | .bin | .SEC | The MODULE_TYPE for a LOGO when migrating to EDK II should be specified as USER_DEFINED. The .bmp file should be include under a [binaries] section. In EDK, the COMPONENT_TYPE of LOGO was used to specify a .bmp file. |
-| `RAWFILE` | .raw | .RAW | |
-| `FVIMAGEFILE` | .fv | .FVI | |
-| `SECURITY_CORE` | .efi | .SEC | Modules of this type are designed to start execution at the reset vector of a CPU. They are responsible for preparing the platform for the PEI Phase. Since there are no standard services defined for SEC, modules of this type follow the same rules as modules of type Base and typically include some amount of CPU specific assembly code to establish temporary memory for a stack. Modules of this type may optionally produce services that are passed to the PEI Phase in HOBs and those services must be compliant with the PEI CIS. |
-| `PEI_CORE` | .efi | .PEI | This module type is used by PEI Core implementations that are complaint with the PEI CIS. |
-| `COMBINED_PEIM_DRIVER` | .efi | .PEI | |
-| `PIC_PEIM` | .efi | .PEI | |
-| `RELOCATABLE_PEIM` | .efi | .PEI | When migrating to EDK II, this type of module should use the register for shadow PPI, and set the [defines] entry: `SHADOW = TRUE` |
-| `PE32_PEIM` | .efi | .PEI | This module type is used by PEIMs that are compliant with the PEI CIS |
-| `BS_DRIVER` | .efi | .DXE | This module type is either the DXE Core or DXE Drivers that are complaint with the DXE CIS. These modules only execute in the boot services environment and are destroyed when ExitBootServices() is called. |
-| `RT_DRIVER` | .efi | .DXE | This module type is used by DXE Drivers that are complaint with the DXE CIS. These modules execute in both boot services and runtime services environments. This means the services that these modules produce are available after ExitBootServices() is called. If SetVirtualAddressMap() is called, then modules of this type are relocated according to virtual address map provided by the operating system. |
-| `SAL_RT_DRIVER` | .efi | .DXE | This module type is used by DXE Drivers that can be called in physical mode before SetVirtualAddressMap() is called and either physical mode or virtual mode after SetVirtualAddressMap() is called. This module type is only available to IPF CPUs. This means the services that these modules produce are available after ExitBootServices(). |
-| `BS_DRIVER` | .efi | .SMM | This module type is used by DXE Drivers that are loaded into SMRAM. As a result, this module type is only available for IA-32 and x64 CPUs. These modules only execute in physical mode, and are never destroyed. This means the services that these modules produce are available after ExitBootServices(). |
-| `APPLICATION` | .efi | .APP | This module type is used by UEFI Applications that are compliant with the EFI 1.10 Specification or the UEFI 2.0 Specification. UEFI Applications are always unloaded when they exit. |
-| `EFI USER INTERFACE` | .ui | .ui | |
-| `EFI VERSION` | .ver | .ver | |
-| `EFI DEPENDENCY` | .dpx | .dpx | |
-
-### A.1.2 [sources] Section
-
-The `[sources]` section is used to specify the files that make up the
-component. Directories names are required for files existing in subdirectories
-of the component. All directory names are relative to the location of the INF
-file. Macros are allowed in the source file path. For EDK builds, each file is
-added to the macro of `$(INC_DEPS)`, which can be used in a makefile dependency
-expression.
-
-This section will typically use one of the following section definitions:
-
-```ini
-[sources]
-[sources.common]
-[sources.IA32]
-[sources.X64]
-[sources.IPF]
-[sources.EBC]
-```
-
-The following example demonstrates entries in this section.
-
-```ini
-[sources.common]
- DxeIpl.dxs
- DxeIpl.h
- DxeLoad.c
-
-[sources.Ia32]
- Ia32/VirtualMemory.h
- Ia32/VirtualMemory.c
- Ia32/DxeLoadFunc.c
- Ia32/ImageRead.c
-
-[sources.X64]
- X64/DxeLoadFunc.c
-
-[sources.IPF]
- Ipf/DxeLoadFunc.c
- Ipf/ImageRead.c
-```
-
-Binary file types - EDK does not have the flexibility of EDK II, but does
-provide a method for specifying binary files in the `[sources]` section. The
-following lists the mapping of EDK specific binary file types to EFI sections.
-
-**_SEC_GUID_**
-
-The binary file is an `EFI_SECTION_FREEFORM_SUBTYPE_GUID` section.
-
-**_SEC_PE32_**
-
-This binary is an `EFI_SECTION_PE32` section.
-
-**_SEC_PIC_**
-
-This binary is an `EFI_SECTION_PIC` section.
-
-**_SEC_PEI_DEPEX_**
-
-This binary is an `EFI_SECTION_PEI_DEPEX` section.
-
-**_SEC_DXE_DEPEX_**
-
-This binary is an `EFI_SECTION_DXE_DEPEX` section.
-
-**_SEC_TE_**
-
-This binary is an `EFI_SECTION_TE` section.
-
-**_SEC_VER_**
-
-This binary is an `EFI_SECTION_VERSION` section.
-
-**_SEC_UI_**
-
-This binary is an `EFI_SECTION_USER_INTERFACE` section.
-
-**_SEC_BIN_**
-
-The binary is an `EFI_SECTION_RAW` section.
-
-**_SEC_COMPAT16_**
-
-This binary is an `EFI_SECTION_COMPATIBILTY16` section.
-
-### A.1.3 [libraries] Section
-
-The `[libraries]` section of the EDK INF is used to list the names of the
-libraries that will be linked into the EDK component. The library names do not
-include the directory locations or the extension name of the file. For each
-library, `{LibName}`, found, the `{LibName}` is added to the LIBS definition in
-the output makefile:
-
-`LIBS = $(LIBS) $(LIB_DIR)\{LibName}`
-
-This section will typically use one of the following section definitions:
-
-```ini
-[libraries.common]
-[libraries.IA32]
-[libraries.X64]
-[libraries.IPF]
-[libraries.EBC]
-```
-
-The formats for entries in this section is:
-
-`LibraryName`
-
-The following is an example of a libraries section.
-
-```ini
-[libraries.common]
- EfiProtocolLib
- EfiDriverLib
-```
-
-### A.1.4 [includes] Section
-
-The `[includes]` section of the EDK INF file is a list of directories to be
-included on the compile command line. These are included in a section of the
-Makefile generated by the parsing utilities. For each include path specified,
-the following line is written to the component's makefile.
-
-`INC = $(INC) -I $(SOURCE_DIR)\{path}`
-
-The path must be absolute, however the use of the global variable, EDK_SOURCE
-is recommended to construct the path.
-
-This section will typically use one of the following section definitions:
-
-```ini
-[includes.common]
-[includes.IA32]
-[includes.X64]
-[includes.IPF]
-[includes.Nt32]
-[include.common]
-[include.IA32]
-[include.X64]
-[include.IPF]
-```
-
-The formats for entries in this section is:
-
-`$(EDK_SOURCE)/path/to/header/files`
-
-The following is an example of the [includes] section.
-
-```ini
-[includes.common]
- $(EDK_SOURCE)FoundationEfi
- $(EDK_SOURCE)Foundation
- $(EDK_SOURCE)FoundationFramework
- .
- $(EDK_SOURCE)FoundationInclude
- $(EDK_SOURCE)FoundationEfiInclude
- $(EDK_SOURCE)FoundationFrameworkInclude
- $(EDK_SOURCE)FoundationIncludeIndustryStandard
- $(EDK_SOURCE)FoundationCoreDxe
- $(EDK_SOURCE)FoundationLibraryDxeInclude
-```
-
-### A.1.5 [nmake] Section
-
-The optional EDK `[nmake]` section may also include a ".ProcessorName" to
-restrict processing based on the processor name. The section data is simply
-copied directly to the component makefile, before the build commands are
-emitted.
-
-This section will typically use one of the following section definitions:
-
-```ini
-[nmake]
-[nmake.common]
-[nmake.IA32]
-[nmake.X64]
-[nmake.IPF]
-[nmake.EBC]
-```
-
-The format for entries in this section is any valid Makefile syntax. Refer to
-make command reference for your tool chains.
-
-The following is an example of the EDK `[nmake]` section.
-
-```ini
-[nmake.common]
- IMAGE_ENTRY_POINT = DiskIoDriverEntryPoint
-```
diff --git a/appendix_a_edk_inf_file_specification/a2_edk_file_specification.md b/appendix_a_edk_inf_file_specification/a2_edk_file_specification.md
deleted file mode 100644
index defbbc2..0000000
--- a/appendix_a_edk_inf_file_specification/a2_edk_file_specification.md
+++ /dev/null
@@ -1,461 +0,0 @@
-<!--- @file
- A.2 EDK File Specification
-
- Copyright (c) 2007-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.
-
--->
-
-## A.2 EDK File Specification
-
-The general rules for all EDK INI style documents follow.
-
-**********
-**Note:** Path and Filename elements within the INF are case-sensitive in order
-to support building on UNIX style operating systems.
-**********
-
-A section terminates with either another section definition or the end of the
-file.
-
-#### Summary
-
-Component EDK INF description
-
-#### Prototype
-
-```c
-<EDK_INF> ::= [<Header>]
- <Defines>
- <Sources>
- [<Includes>]
- [<Libraries>]
- [<Nmake>]
-```
-
-### A.2.1 Header Section
-
-#### Summary
-
-This section contains Copyright and License notices for the INF file in
-comments that start the file. This section is optional using a format of:
-
-
-```ini
-#/*++
-#
-# Copyright
-# License
-#
-# Module Name:
-# EdkFrameworkProtocolLib.inf
-#
-# Abstract:
-#
-# Component description file.
-#
-#--*/
-```
-
-This information a developer creating a new EDK component or library
-information (INF) file.
-
-This is an optional section.
-
-#### Prototype
-
-```c
-<Header> ::= ["#"] "/*++" <EOL>
- [<Copyright>]
- [<License>]
- [<ModuleName>]
- [<Abstract>]
- ["#"] "--*/" <EOL>
-<Abstract> ::= ["#"] "Abstract:" <EOL>
- [["#"] <Sentence> <EOL>]*
- ["#"] <EOL>
-<ModuleName> ::= ["#"] "Module Name:" <EOL>
- [["#"] <Sentence>+ <EOL>]+
- ["#"] <EOL>
-<Copyright> ::= [["#"] "Copyright (c) <Date> "," <CompExtra> <EOL>]+ ["#"]
- <EOL>
-<License> ::= [["#"] <LicenseSentence> <EOL>]+
- ["#"] <EOL>
-```
-
-#### Example
-
-```
-#/*++
-#
-# Copyright (c) 2004, Intel Corporation
-# All rights reserved. This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the
-# BSD License which accompanies this distribution. The full text of the
-# license may be found at
-# http://opensource.org/licenses/bsd-license.php
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
-# IMPLIED.
-#
-# Module Name:
-#
-# EdkFrameworkProtocolLib.inf
-#
-# Abstract:
-#
-# Component description file.
-#
-#--*/
-```
-
-### A.2.2 [defines] Section
-
-#### Summary
-
-This describes the required `[define]` tag, which is required in all EDK INF
-files. This file is created by the developer and is an input to the new build
-tool parsing utilities. Elements may appear in any order within this section.
-
-This is a required section.
-
-The define sections defines symbols that describe the component. Some items are
-emitted to the output makefile.
-
-The `FILE_GUID` is required for all EDK components that are not libraries. This
-guid is used to build the FW volume file list used by build tools to generate
-the final firmware volume, as well as processed in some SMM, PEI or DXE DEPEX
-statements.
-
-**********
-**Note:** Possible values for `COMPONENT_TYPE`, and their descriptions, are
-listed in the table, "Component (module) Types." For each component, the
-`BASE_NAME` and `COMPONENT_TYPE` are required. The `COMPONENT_TYPE` definition
-is case sensitive. The default FV extension can be overridden by defining the
-symbol `FV_EXT`.
-**********
-
-Section `[defines.$(PROCESSOR).$(PLATFORM)]` is used with EDK components only.
-The section is processed in order by the parsing utilities. Assignments of
-variables in other sections do not override previous assignments.
-
-Platform integrators that will be using EDK components that require a static
-FlashMap.h (and/or FlashMap.inc) must code them by hand and maintain the state
-of the static FlashMap files with the EDK II DSC and FDF files.
-
-#### Prototype
-
-```c
-<Defines> ::= "[defines" [<attribs>] "]" <EOL> <expression>+
-<attribs> ::= <attrs> ["," "defines" <attrs>]*
-<attrs> ::= "." <arch> ["." <PlatformName>]
-<arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"}
-<PlatformName> ::= {<Word>} {"$(PLATFORM)") {"platform"}
-<expression> ::= "BASE_NAME" "=" <Word> <EOL>
- ["COMPONENT_TYPE" "=" <EdkCompType> <EOL>]
- ["FILE_GUID" "=" <GuidOrVar> <EOL>]
- ["EDK_RELEASE_VERSION" "=" "0x00020000" <EOL>]
- ["MAKEFILE_NAME" "=" <Filename> <EOL>]
- ["CUSTOM_MAKEFILE" "=" <Filename> <EOL>]
- ["BUILD_NUMBER" "=" <Integer>{1,4} <EOL>]
- ["BUILD_TYPE" "=" <MakefileType> <EOL>]
- ["FFS_EXT" "=" <Word> <EOL>]
- ["FV_EXT" "=" <Word> <EOL>]
- ["SOURCE_FV" "=" <Word> <EOL>]
- ["PACKAGE" "=" "CompressPEIM" <EOL>]
- ["VERSION_NUMBER" "=" <Integer>{1,4} <EOL>]
- ["VERSION_STRING" "=" <String> <EOL>]
- ["GENERIC_CAPSULE_FILE_PATH" "=" <PathOnly> <EOL>]
- ["MICROCODE_ALIGNMENT" "=" <HexNumber> <EOL>]
- ["MICROCODE_FILE_PATH" "=" <PathOnly> <EOL>]
- ["PLATFORM_BDS_FILE_PATH" "=" <PathOnly> <EOL>]
- ["RESTRICTED_BDS_FILE_PATH" "=" <PathOnly> <EOL>]
-<Filename> ::= [<PATH>] <Word> ["." <Extension>]
-<PathOnly> ::= <PATH> <Word>
-<MakefileType> ::= {"MAKEFILE"} {"CUSTOM_MAKEFILE"} {<Filename>}
-<PATH> ::= [<Variable> "\"] <Path>
-<Path> ::= [{<Word> "\"} {"..\"}]+
-<Variable> ::= {"$(" <MacroName> ")"}
- {"$(EFI_SOURCE)"} {"$(EDK_SOURCE)"}
-<GuidOrVar> ::= {<RegistryFormatGUID>}
- {"$(EFI_APRIORI_GUID)"}
- {"$(EFI_ACPI_TABLE_STORAGE_GUID)"}
- {"$(EFI_DEFAULT_BMP_LOGO_GUID)"}
- {"$(EFI_PEI_APRIORI_FILE_NAME_GUID)"}
-<EdkCompType> ::= {"APPLICATION"} {"AcpiTable"} {"APRIORI"}
- {"BINARY"} {"BS_DRIVER"} {"CONFIG"} {"FILE"}
- {"FVIMAGEFILE"} {"LIBRARY"} {"LOGO"} {"LEGACY16"}
- {"MICROCODE"} {"PE32_PEIM"} {"PEI_CORE"}
- {"RAWFILE"} {"RT_DRIVER"} {"SAL_RT_DRIVER"}
- {"SECURITY_CORE"} {"COMBINED_PEIM_DRIVER"} {"PIC_PEIM"}
- {"RELOCATABLE_PEIM"}
-<MacroName> ::= <Word>
-```
-
-#### Example (EDK Driver)
-
-```ini
-[Defines]
- BASE_NAME = DiskIo
- FILE_GUID = CA261A26-7718-4b9b-8A07-5178B1AE3A02
- COMPONENT_TYPE = BS_DRIVER
-```
-
-#### Example (EDK Library)
-
-```ini
-[Defines]
- BASE_NAME = WinNtLib
- COMPONENT_TYPE = LIBRARY
-```
-
-### A.2.3 [includes] Section
-
-#### Summary
-
-Defines the optional "includes paths" for EDK INF files only. These sections
-should never be used in EDK II INF files. These sections are used to define the
-include paths for compiling the component source files. Valid sections for EDK
-include the `[includes.$(PROCESSOR).$(PLATFORM)]`, `[includes.$(PROCESSOR)]`,
-and `[includes.common]` sections.
-
-**********
-**NOTE**: EDK uses both "include" and "includes" section header types. These
-sections are processed if present. These paths are used to define the `$(INC)`
-macro and is written to the component's makefile.
-**********
-
-This is an optional section.
-
-The standard Macro Definitions are not permitted within this section.
-
-For EDK modules, the path must include either the `$(EFI_SOURCE)` or
-`$(EDK_SOURCE)` environment variable.
-
-This section also allows for specifying individual header files that will be
-added to the `$(INC)` macro using the `/FI` (Microsoft) or `-include` (GCC)
-switch. This is an optional section.
-
-#### Prototype
-
-```c
-<Includes> ::= "[include" ["s"] [<Attrs>] ']" <EOL>
- <PATH>+
-<Attrs> ::= <Attributes> ["," "include" ["s"]? <Attrs>]*
-<Attributes> ::= [<Archs>] [<VarName>] [<Platform>]
-<Archs> ::= "." <arch>
-<arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} {<OA>}
-<VarName> ::= "." {"$(PROCESSOR)"} {"$(" <Word> ")"}
-<Platform> ::= "." {"Platform") {"nt32"} {"$(PLATFORM)"}
-<PATH> ::= {<MACRO>} {<RelDir>}
-<MACRO> ::= <MacroName> ["\" <Word>]+
-<MacroName> ::= {"$(EDK_SOURCE)"} {"$(EFI_SOURCE)"} {"$(BUILD_DIR)"}
- {"$(SOURCE_DIR)"}
-<RelDir> ::= ["..\"]+ {".."} {<Word>}
-```
-
-#### Example
-
-```ini
-[Includes.common]
- $(EDK_SOURCE)FoundationEfi
- $(EDK_SOURCE)Foundation
- $(EDK_SOURCE)FoundationFramework
- .
- $(EDK_SOURCE)FoundationInclude
- $(EDK_SOURCE)FoundationEfiInclude
- $(EDK_SOURCE)FoundationFrameworkInclude
- $(EDK_SOURCE)FoundationIncludeIndustryStandard
- $(EDK_SOURCE)FoundationCoreDxe
- $(EDK_SOURCE)FoundationLibraryDxeInclude
-```
-
-### A.2.4 [libraries] Section
-
-#### Summary
-
-Defines the optional `[libraries]` section tag for EDK INF files. The
-`[libraries]` section is used to define a `$(LIBS)` macro in the EDK component's
-makefile. All libraries listed in the `[libraries.common]`,
-`[libraries.$(PROCESSOR)]`, and `[libraries.$(PROCESSOR).$(PLATFORM)]` sections
-are added to the LIBS definition as either `$(LIB_DIR)\LibName` or
-`$(PROCESSOR)\LibName`. The libraries are specified without path information.
-
-The standard Macro Definitions are not permitted in this section.
-
-This is an optional section.
-
-#### Prototype
-
-```c
-<Libraries> ::= "[libraries" [<attrs>] ']" <EOL> <LibName>+
-<attrs> ::= "." <archs> ["." <platform>]
-<archs> ::= <arch> ["," <arch> ["." <platform>]]
- ["," "libraries." <attrs>]*
-<arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"}
- {"platform"} {"nt32"} {"$(PROCESSOR)"}
-<platform> ::= {"platform"} {"$(PLATFORM)"} {<Word>}
-<LibName> ::= <Word>
-```
-
-#### Example
-
-```ini
-[Libraries.common]
- EfiProtocolLib
- EfiDriverLib
-```
-
-### A.2.5 [nmake] Section
-
-#### Summary
-
-Defines the [nmake] section tag for EDK INF files. These sections are used to
-make a direct addition to the component's output makefile. EFI section
-`[nmake.$(PROCESSOR).$(PLATFORM)]`, `[nmake.$(PROCESSOR)]`, and `[nmake.common]`
-are processed if present. The section data is simply copied directly to the
-component makefile, before the build commands are emitted. Filenames specified
-in this section are relative to the EDK INF file or the EDK DSC file.
-
-This is an optional section.
-
-This section is not permitted in EDK II modules. Note that the `C_STD_INCLUDE`
-line is usually used to clear any flags that might have been set by the
-Microsoft tool chain setup scripts, therefore no `<CFlags>` are printed, and
-the line in the Example is the most common usage.
-
-The standard Macro Definitions are not permitted in this section.
-
-#### Prototype
-
-```c
-<Nmake> ::= "[nmake" [<attrs>] ']" <EOL>
- <expression>+
-<attrs> ::= <Archs> [<plat>] ["," "nmake" <attrs>]*
-<Archs> ::= "." <arch>
-<plat> ::= "." <Word>
-<arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"}
-<expression> ::= [<IEP>] [<DS>] [<CSI>] [<CPF>] [<APF>] [<LSF>] [<EBC>] [<DEF>]
-<IEP> ::= "IMAGE_ENTRY_POINT" "=" <CName> <EOL>
-<DS> ::= "DPX_SOURCE" "=" <Filename> <EOL>
-<CSI> ::= "C_STD_INCLUDE" "=" [<CFlags>] <EOL>
-<CPF> ::= "C_PROJ_FLAGS" "=" <CFlags> <EOL>
-<APF> ::= "ASM_PROJ_FLAGS" "=" <AFlags> <EOL>
-<LSF> ::= "LIB_STD_FLAGS" "=" <LFlags> <EOL>
-<EBC> ::= ["EBC_C_STD_FLAGS" "=" <String> <EOL>]
- ["EBC_LIB_STD_FLAGS" "=" <String> <EOL>]
-<DEF> ::= <Word> "=" {<Word>} {<String>} <EOL>
-<STATEMENTS> ::= Valid NMAKE Makefile syntax.
-```
-
-#### Parameters
-
-**_CFlags_**
-
-This content must be valid compiler flags for the Microsoft C compiler, cl.exe.
-
-**_AFlags_**
-
-This content must be valid flags for the Microsoft Assembler, ml.exe.
-
-**_LFlags_**
-
-This content must be valid flags for the Microsoft Linker, lib.exe.
-
-#### Example
-
-```ini
-[nmake.common]
- C_STD_INCLUDE =
- IMAGE_ENTRY_POINT=WatchdogTimerDriverInitialize
- DPX_SOURCE=WatchDogTimer.dxs
-
-[nmake.common]
- C_FLAGS = $(C_FLAGS) /D EDKII_GLUE_LIBRARY_IMPLEMENTATION
- LIB_STD_FLAGS = $(LIB_STD_FLAGS) /IGNORE:4006 /IGNORE:4221
-
-[nmake.ia32]
- C_FLAGS = $(C_FLAGS) /D MDE_CPU_IA32
-
-[nmake.x64]
- C_FLAGS = $(C_FLAGS) /D MDE_CPU_X64
-
-[nmake.ipf]
- C_FLAGS = $(C_FLAGS) /D MDE_CPU_IPF
-
-[nmake.ebc]
- EBC_C_STD_FLAGS = $(EBC_C_STD_FLAGS) /D EDKII_GLUE_LIBRARY_IMPLEMENTATION
- EBC_LIB_STD_FLAGS = $(EBC_LIB_STD_FLAGS) /IGNORE:4006 /IGNORE:4221
- EBC_C_STD_FLAGS = $(EBC_C_STD_FLAGS) /D MDE_CPU_EBC
-```
-
-### A.2.6 [sources] Section
-
-#### Summary
-
-Defines the `[sources]` section tag is required for EDK INF files. NOTE: EDK
-uses both "source" and "sources" in the section header.
-
-There can be multiple sources sections, depending on the target processor.
-Example sources sections are listed below. The parsing utility creates a
-directory path for each file (`$(DEST_DIR)...\MyFile.c`), and looks up the
-makefile template for the `COMPONENT_TYPE` (EDK) to emit.
-
-It is not permissible to mix EDK and EDK II style files within a module.
-
-The macro, TABLE_NAME may be used in existing EDK INF files that point to ACPI
-tables, this value wil be ignored by EDK II build tools.
-
-#### Prototype
-
-```c
-<sources> ::= "[source" ["s"] [<attrs>] "]" <EOL>
- [<MacroDefinition>]* [<EdkExpression>]+
-<attrs> ::= <Archs> ["," "sources" <attrs>]*
-<Archs> ::= if (COMPONENT_TYPE defined in defines):
- "." <archs> [<plat>] else:
- "." <archs>
-<archs> ::= if (COMPONENT_TYPE defined in defines): <EdkArch> [","
- <EdkArch>]* else:
- <arch> ["|" <arch>]*
-<EdkArch> ::= {"IA32"} {"X64"} {"IPF"} {"Common"}
-<plat> ::= "." {"$(PLATFORM)"} {"$(PROCESSOR)"} {<Word>}
-<DefineStatement> ::= ["DEFINE" <Word> "=" [<PATH>] <EOL>]*
- ["TABLE_NAME" "=" <Word> <EOL>]
-<EdkExpression> ::= <Filename> ["|" <Family>] <EOL>
-<Family> ::= {"MSFT"} {"GCC"} {"INTEL"} {"*"}
-<Filename> ::= <Path> <Word> "." <Extension>
-<Path> ::= [<Macro> {"\"} {"/"}] [<Word> {"\"} {"/"}]+
-```
-
-#### Examples
-
-```ini
-[sources.common]
- BsDataHubStatusCode.c
- BsDataHubStatusCode.h
-```
diff --git a/appendix_c_symbols.md b/appendix_b_symbols.md
similarity index 100%
rename from appendix_c_symbols.md
rename to appendix_b_symbols.md
diff --git a/appendix_d_sample_driver_inf_files.md b/appendix_c_sample_driver_inf_files.md
similarity index 100%
rename from appendix_d_sample_driver_inf_files.md
rename to appendix_c_sample_driver_inf_files.md
diff --git a/appendix_e_sample_library_inf_files.md b/appendix_d_sample_library_inf_files.md
similarity index 100%
rename from appendix_e_sample_library_inf_files.md
rename to appendix_d_sample_library_inf_files.md
diff --git a/appendix_f_sample_binary_inf_files.md b/appendix_e_sample_binary_inf_files.md
similarity index 100%
rename from appendix_f_sample_binary_inf_files.md
rename to appendix_e_sample_binary_inf_files.md
diff --git a/appendix_g_module_types.md b/appendix_f_module_types.md
similarity index 100%
rename from appendix_g_module_types.md
rename to appendix_f_module_types.md
--
2.18.0.windows.1
next reply other threads:[~2019-03-04 13:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-04 13:52 Feng, Bob C [this message]
2019-03-06 8:01 ` [Patch] Document: Update Inf spec to remove EDK related contents Gao, Liming
2019-03-06 8:48 ` Feng, Bob C
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=20190304135205.3616-1-bob.c.feng@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