From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.100; helo=mga07.intel.com; envelope-from=bob.c.feng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 71BBD211D56C4 for ; Wed, 6 Mar 2019 00:48:49 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2019 00:48:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,447,1544515200"; d="scan'208";a="304803209" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga005.jf.intel.com with ESMTP; 06 Mar 2019 00:48:48 -0800 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 6 Mar 2019 00:48:48 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 6 Mar 2019 00:48:47 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.158]) by shsmsx102.ccr.corp.intel.com ([169.254.2.163]) with mapi id 14.03.0415.000; Wed, 6 Mar 2019 16:48:43 +0800 From: "Feng, Bob C" To: "Gao, Liming" , "edk2-devel@lists.01.org" CC: "Carsey, Jaben" Thread-Topic: [edk2] [Patch] Document: Update Inf spec to remove EDK related contents Thread-Index: AQHU0pGFFY2AghrcokuFRhiwfBd1j6X9umcAgACRAQA= Date: Wed, 6 Mar 2019 08:48:42 +0000 Message-ID: <08650203BA1BD64D8AD9B6D5D74A85D1600A9325@SHSMSX101.ccr.corp.intel.com> References: <20190304135205.3616-1-bob.c.feng@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E3FC382@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3FC382@SHSMSX104.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [Patch] Document: Update Inf spec to remove EDK related contents X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 08:48:49 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Liming, I'll update patch for 1) and 2) For 3) This patch removed "and are valid for EDK-II modules only." Because I thin= k there is only EDK-II now, we don't need to point out this section is for = EDKII ONLY here. Thanks, Bob -----Original Message----- From: Gao, Liming=20 Sent: Wednesday, March 6, 2019 4:02 PM To: Feng, Bob C ; edk2-devel@lists.01.org Cc: Carsey, Jaben Subject: RE: [edk2] [Patch] Document: Update Inf spec to remove EDK related= contents Bob: I have some comments.=20 1) Please update the commit message. The change is to remove EDK and IPF re= lated contents.=20 2) The below change should make sure the updated one keep the same alignmen= t.=20 -|----------------------------|- +|----------------------------| 3) Below content is correct. It is for EDKII. No need to change it.=20 -These sections are used for specifying PCD information and are valid for E= DK -II modules only. The entries for these sections are looked up from the pac= kage -declaration files (DEC) for generating the `AutoGen.c` and `AutoGen.h` fil= es. +These sections are used for specifying PCD information. The entries for th= ese=20 +sections are looked up from the packagedeclaration files (DEC) for generat= ing=20 +the `AutoGen.c` and `AutoGen.h` files. Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Fe= ng, Bob C > Sent: Monday, March 4, 2019 5:52 AM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben ; Gao, Liming > Subject: [edk2] [Patch] Document: Update Inf spec to remove EDK related c= ontents >=20 > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1453 >=20 > Remove EDK related contents >=20 > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Bob Feng > Cc: Liming Gao > Cc: Jaben Carsey > --- > 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 =3D> appendix_b_symbols.md | 0 > ...d =3D> appendix_c_sample_driver_inf_files.md | 0 > ... =3D> appendix_d_sample_library_inf_files.md | 0 > ...d =3D> appendix_e_sample_binary_inf_files.md | 0 > ...ule_types.md =3D> appendix_f_module_types.md | 0 > 31 files changed, 30 insertions(+), 932 deletions(-) > rename appendix_b_build_changes_and_customizations.md =3D> appendix_a_bu= ild_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_discu= ssion.md > delete mode 100644 appendix_a_edk_inf_file_specification/a2_edk_file_spe= cification.md > rename appendix_c_symbols.md =3D> appendix_b_symbols.md (100%) > rename appendix_d_sample_driver_inf_files.md =3D> appendix_c_sample_driv= er_inf_files.md (100%) > rename appendix_e_sample_library_inf_files.md =3D> appendix_d_sample_lib= rary_inf_files.md (100%) > rename appendix_f_sample_binary_inf_files.md =3D> appendix_e_sample_bina= ry_inf_files.md (100%) > rename appendix_g_module_types.md =3D> appendix_f_module_types.md (100%) >=20 > diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.m= d > 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 for= mats. Changes made to this > specification must not require changes to existing INF files. >=20 > **Simplified platform build and configuration** >=20 > Simplify the build setup and configuration for a given platform. The pro= cess of > -adding EDK and EDK II firmware components to a firmware volume on any gi= ven > +adding EDK II firmware components to a firmware volume on any given > platform was also simplified. >=20 > **Distributing Modules** >=20 > Enable easy distribution of modules, both in source and binary form. Ind= ividual > diff --git a/2_inf_overview/210_[ppis]_section.md b/2_inf_overview/210_[p= pis]_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 defini= tions: > ```ini > [Ppis] > [Ppis.common] > [Ppis.IA32] > [Ppis.X64] > -[Ppis.IPF] > [Ppis.EBC] > ``` >=20 > The formats for entries in this section is: >=20 > 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 defini= tions: > ```ini > [Guids] > [Guids.common] > [Guids.IA32] > [Guids.X64] > -[Guids.IPF] > [Guids.EBC] > ``` >=20 > The formats for entries in this section is: >=20 > diff --git a/2_inf_overview/212_[libraryclasses]_section.md b/2_inf_overv= iew/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 defini= tions: > ```ini > [LibraryClasses] > [LibraryClasses.common] > [LibraryClasses.IA32] > [LibraryClasses.X64] > -[LibraryClasses.IPF] > [LibraryClasses.EBC] > ``` >=20 > The format for entries in this section is: >=20 > diff --git a/2_inf_overview/213_[packages]_section.md b/2_inf_overview/21= 3_[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 defini= tions: > ```ini > [Packages] > [Packages.common] > [Packages.IA32] > [Packages.X64] > -[Packages.IPF] > [Packages.EBC] > ``` >=20 > The path must include the DEC file name and the name of the directory th= at > 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 @@ >=20 > --> >=20 > ## 2.14 PCD Sections >=20 > -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 p= ackage > -declaration files (DEC) for generating the `AutoGen.c` and `AutoGen.h` f= iles. > +These sections are used for specifying PCD information. The entries for = these > +sections are looked up from the packagedeclaration files (DEC) for gener= ating > +the `AutoGen.c` and `AutoGen.h` files. >=20 > 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 identi= fied > using the following format to identify the named PCD: >=20 > @@ -43,11 +43,11 @@ using the following format to identify the named PCD: >=20 > PCDs listed in architectural sections must not be listed in common > architectural sections. It is not possible for a PCD to be valid for onl= y IA32 > and also valid for any architecture. >=20 > -A PCD may be valid for IA32 and X64 and invalid for EBC and IPF usage, s= o > +A PCD may be valid for IA32 and X64 and invalid for EBC usage, so > mixing of specific architectural modifiers is permitted. >=20 > 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 fo= r 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] > ``` >=20 > The required entries for this section are the PCD Token Space Guid C Nam= e'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] > ``` >=20 > The following is an example of the `PCD FIXED_AT_BUILD` type: >=20 > @@ -167,11 +165,10 @@ character. This section uses one of the following s= ection definitions: >=20 > ```ini > [PatchPcd] > [PatchPcd.IA32] > [PatchPcd.X64] > -[PatchPcd.IPF] > [PatchPcd.EBC] > [PatchPcd.common] > ``` >=20 > 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 fo= llowing section definitions: > ```ini > [FeaturePcd] > [FeaturePcd.common] > [FeaturePcd.IA32] > [FeaturePcd.X64] > -[FeaturePcd.IPF] > [FeaturePcd.EBC] > ``` >=20 > The following is an example of the PCD `FEATURE_FLAG` type: >=20 > @@ -221,11 +217,10 @@ following section definitions: > ```ini > [Pcd] > [Pcd.common] > [Pcd.IA32] > [Pcd.X64] > -[Pcd.IPF] > [Pcd.EBC] > ``` >=20 > The following is an example of the PCD `DYNAMIC` type: >=20 > @@ -247,11 +242,10 @@ format. This section uses one of the following sect= ion definitions: > ```ini > [PcdEx] > [PcdEx.common] > [PcdEx.IA32] > [PcdEx.X64] > -[PcdEx.IPF] > [PcdEx.EBC] > ``` >=20 > The following is an example of the PCD `DYNAMIC_EX` type: >=20 > 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 @@ >=20 > --> >=20 > ## 2.15 [Depex] Section >=20 > -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 f= ile. 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. >=20 > @@ -87,11 +84,10 @@ The Depex section headers start with one of the follo= wing: >=20 > ```ini > [Depex] > [Depex.IA32] > [Depex.X64] > -[Depex.IPF] > [Depex.EBC] > [Depex.common] > ``` >=20 > 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 manne= r > similar to the other build meta-data files. However, the intent of a mod= ule's > INF file is to define the source files, libraries, and definitions relev= ant to > building the module, creating binary files that are either raw binary fi= les or > PE32/PE32+/coff format files. The different sections are described in de= tail in > -this chapter. In general, the original EDK parsing utilities read each l= ine > -from the `[Libraries]` or `[Components]` sections of the build descripti= on > -(DSC) file, process the INF file on a line to generate a makefile, and t= hen > -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 bo= th EDK > -and EDK II INF files, and, if required, generate C code files based on t= he > -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 develope= rs 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 an= d > -operating systems is their ability to process the forward slash "/" char= acter > -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 au= togenerated files. >=20 > All EDK II INF files MUST use this forward slash character for all direc= tory > 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 @@ >=20 > --> >=20 > ## 2.2 Information File General Rules >=20 > -This section covers the format for the EDK II module INF files. While th= e 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. >=20 > ### 2.2.1 Section Entries >=20 > -To simplify parsing, the EDK II meta-data files continue using the INI f= ormat. > -This style was introduced for EDK meta-data files, when only the Windows= tool > -chains were supported. It was decided that for compatibility purposes, t= hat 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 ";" charact= er cannot > +be used to indicate a comment in the EDK II format. >=20 > Leading and trailing space/tab characters must be ignored. >=20 > Duplicate section names must be merged by tools. >=20 > @@ -52,11 +48,11 @@ This description file consists of sections delineated= by section tags enclosed > within square `[]` brackets. Section tag entries are case-insensitive. T= he > different sections and their usage are described below. The text of a gi= ven > section can be used for multiple section names by separating the section= names > with a comma. For example: >=20 > -`[Sources.X64, Sources.IPF]` > +`[Sources.X64, Sources.IA32]` >=20 > The content below each section heading is processed by the parsing utili= ties in > the order that they occur in the file. The precedence for processing the= se > 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 supp= ort. > * All files (except those listed in the Packages sections) must reside i= n the > directory containing the INF file or in sub-directories of the directo= ry > containing the INF file. >=20 > * Additionally, all EDK II directories that are architecturally dependen= t must > - use a name with only the first character capitalized. Ia32, Ipf, X64 a= nd Ebc > - are valid architectural directory names. IA32, IPF and EBC are not acc= eptable > - directory names, and may cause build breaks. From a build tools perspe= ctive, > - IA32 is not equivalent to Ia32 or ia32. > + use a name with only the first character capitalized. Ia32 is valid ar= chitectural > + 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. >=20 > * Absolute paths are not permitted in EDK II INF files. All paths specif= ied are > relative to an EDK II package directory (defined as a directory contai= ning a > DEC file) or relative to the directory containing the INF file. >=20 > @@ -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 cont= ent of > the INF files. >=20 > -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. Addition= ally, > -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 n= ame > only. >=20 > 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 =3D $(MDE)/PeiMemoryAllocationLib > MemoryAllocationLib|$(MDEMEM)/PeiMemoryAllocationLib.inf >=20 > -[LibraryClasses.IPF] > - # Cannot use $(PERF) or $(MDEMEM) > - # Can use $(MDE) from the common section > - PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf > - TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf > ``` >=20 > In the previous example, the directory and filename for a library instan= ce is > the recommended instance and may not be the actual library linked to the > module, as the platform integrator may choose a different library instan= ce 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. > ********** >=20 > ###### Table 1 EDK II [Defines] Section Elements >=20 > |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 na= me. > | > |`PI_SPECIFICATION_VERSION` |Not required = |Decimal or special format of > hex| The minimum revision value across the module and all its dependent l= ibraries. 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 disa= bles 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 m= odule 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 l= ibraries. 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 disa= bles checking. > | > | | = | > | The `UEFI_SPECIFICATION_VERSIon` must only be set in the INF file if th= e 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_SPECIFICA= TION_VERSION` must be 0x00020014 | > -|`FILE_GUID` |REQUIRED = |GUID Value > | Registry (8-4-4-4-12) Format. This value is required for all EDK II for= mat 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 for= mat 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 dur= ing 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 fil= e 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; REQUIR= ED for Library only|Word | TypeList | One > Library Class that is satisfied by this Library Instance; one or more `LI= BRARY_CLASS` lines may be specified by a module. The reserved > keyword, NULL, must be listed for library class instances that do NOT sup= port 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] > ``` >=20 > The formats for entries in this section are: >=20 > @@ -91,13 +90,10 @@ The following is an example for sources sections. > Ia32/DxeLoadFunc.c Ia32/ImageRead.c >=20 > [Sources.X64] > X64/DxeLoadFunc.c >=20 > -[Sources.IPF] > - Ipf/DxeLoadFunc.c > - Ipf/ImageRead.c > ``` >=20 > All Unicode files must be listed in the source section. If a Unicode fil= e, > `A.uni`, has the statement: `#include B.uni`, and `B.uni` has a statemen= t: > `#include C.uni`, both `B.uni` and `C.uni` files must be listed in the I= NF > 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 t= he `FAMILY` values, for example: `MSFT`, `INTEL` or `GCC`. > Typically, this field is used to help the build tools determine whether t= he 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 =3D * | `Conf/tools_def.txt` file de= fines two values: `DEBUG` and `RELEASE`. Developers may define > additional targets. > | > | `TAGNAME` | YES | Yes =3D * | `Conf/tools_def.txt` file de= fines 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 =3D * | `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 =3D * | `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 PP= C or ARM may be added as support becomes available. | > | `TOOLCODE` | YES | NO | The tool code must be one of t= he 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. > | >=20 > -********** > -**Note:** Regarding the EDK and EDK II distinctions in the table: Many E= DK 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 Append= ix 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 sect= ion. > The EDK II build is designed to support multiple compilers and tool chai= ns, > expecting that code is written in ANSI C. If custom tool flags are requi= red 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 defini= tions: > ```ini > [Binaries] > [Binaries.common] > [Binaries.IA32] > [Binaries.X64] > -[Binaries.IPF] > [Binaries.EBC] > ``` >=20 > The formats for entries in this section are: >=20 > @@ -193,10 +192,6 @@ The following are examples of different types of `[B= inaries]` sections. > PE32|Ia32/RELEASE/DxeIpl.efi|RELEASE # MYTOOLS DISPOSABLE|Ia32/DEBUG/= DxeIpl.pdb >=20 > [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 defini= tions: > ```ini > [Protocols] > [Protocols.common] > [Protocols.IA32] > [Protocols.X64] > -[Protocols.IPF] > [Protocols.EBC] > ``` >=20 > The formats for entries in this section is: >=20 > 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 librar= y class. The use of > library class API headers allows for platform integrators to select a li= brary > 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. >=20 > -Each module may have one or more INF files that can be used by tools to > -generate images. Specifically, the EDK Compatibility Package will contai= n 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 cap= ability > -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 f= ilename > -of the EDK II build system compatible INF files for non-Windows based to= ol > -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 i= n order > to support building on UNIX style operating systems. > ********** > **Note:** GUID values are used during runtime to uniquely map the C name= s 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 >=20 > #### Summary >=20 > Defines the optional EDK II INF file `[Depex]` section content. The `[De= pex]` > 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 differe= nt > -Depex expressions together. > +writer. This section can be used for inheritance from libraries, by supp= orting > +logical AND'ing of the different Depex expressions together. >=20 > The Rules would be as follows: >=20 > * EDK II INF - `[Depex]` section and inheritance from libraries is suppo= rted > via AND'ing the different Depex expressions together > diff --git a/3_edk_ii_inf_file_format/315_[binaries]_section.md b/3_edk_i= i_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. >=20 > [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 multip= le section types. > ::=3D [" " ]* > ::=3D {} {} > ::=3D {} {} > ::=3D 0x0D 0x0A > ::=3D (a-zA-Z)(a-zA-Z0-9)* > - ::=3D {"IA32"} {"X64"} {"IPF"} {"EBC"} {} > + ::=3D {"IA32"} {"X64"} {"EBC"} {} > ::=3D {"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. >=20 > **_OA_** >=20 > 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. >=20 > **_ExtendedLine_** >=20 > 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 proce= ss > this version of the specification can also process earlier versions of > EDK II INF files. >=20 > -This version of the specification removes content in this section that w= as > -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_N= AME` > 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. > ********** >=20 > -Unlike EDK, only the `[Defines]` section tag is valid for EDK II INF fil= es - > +Only the `[Defines]` section tag is valid for EDK II INF files - > architectural modifiers for the `[Defines]` section tag are not permitte= d. The > section is processed in order by the parsing utilities. Assignments of > variables in other sections override previous assignments. >=20 > The `SHADOW` keyword is only valid for `SEC`, `PEI_CORE` and `PEIM` modu= le > diff --git a/3_edk_ii_inf_file_format/35_[buildoptions]_sections.md b/3_e= dk_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. > ::=3D {} {Target} > ::=3D {} {TagName} > ::=3D CommandCode > ::=3D CommandExecutable > ::=3D Attribute > - ::=3D {"IA32"} {"X64"} {"IPF"} {"EBC"} {} > + ::=3D {"IA32"} {"X64"} {"EBC"} {} > {} > ::=3D (0x20 - 0x7e)+ > ::=3D > ::=3D {} { } > ::=3D {(a-zA-Z) ":\"} {"\"} {"/"} > @@ -179,11 +179,11 @@ A keyword that uniquely identifies the tool chain t= arget architecture; the > third field. This flag is used to support the cross-compiler features, s= uch 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 targ= et > 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 sing= le 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 charact= er, > "``*", is permitted if and only if the same tool is used for all target > architectures. >=20 > @@ -258,7 +258,6 @@ strings. > *_WINDDK3790x1830_*_CC_FLAGS =3D /Qwd1418,810 > *_MYTOOLS_*_CC_FLAGS =3D /Qwd1418,810 > *_VS2003_*_CC_FLAGS =3D /wd4244 > *_WINDDK3790x1830_*_CC_FLAGS =3D /wd4244 > *_MYTOOLS_*_CC_FLAGS =3D /wd4244 > - RELEASE_MYTOOLS_IPF_ASM_FLAGS =3D =3D -N us -X explicit -M ilp64 - N s= o -W3 MSFT:*_*_*_*_FLAGS =3D /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 loca= ted in the same directory > as the INF file. Absolute paths in the filename are prohibited. >=20 > There can be multiple sources sections, depending on the target processo= r. > Example sources sections are listed below. The parsing utility creates a > directory path for each file (`$(DEST_DIR)...\MyFile.c`), and looks up t= he > -makefile template for the `COMPONENT_TYPE` (EDK) or `MODULE_TYPE` (EDK I= I) to > +makefile template for the `MODULE_TYPE` (EDK II) to > emit. >=20 > -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 a= ny > other "source" type file, such as local module header files, Vfr files, = etc. >=20 > 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_forma= t/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 >=20 > This section of the document describes the EDK II INF sections using an > Extended Backus-Naur Form. >=20 > -********** > -**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 @@ > - > - > -# 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 t= he > -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 creat= e a > -distribution that complies with the UEFI Platform Initialization Distrib= ution > -Package Specification. > diff --git a/appendix_a_edk_inf_file_specification/a1_design_discussion.m= d > 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 @@ > - > - > -## 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 utili= ties > -process local symbol assignments made in this section. Note that the sec= tions > -are processed in the order listed here, and later assignments of these l= ocal > -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. ED= K II INF > -files must use the 'defines' keyword. > -********** > - > -The format for entries in this section is: > - > -`Name =3D Value` > - > -The following is an example of this section. > - > -```ini > -[defines] > - BASE_NAME =3D DiskIo > - FILE_GUID =3D CA261A26-7718-4b9b-8A07-5178B1AE3A02 > - COMPONENT_TYPE =3D 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 na= me. > | > -| `COMPONENT_TYPE` | Yes = | One of the EDK I > Component Types | See Table EDK I Componen= t (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, inste= ad 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 fi= les. > | > -| `C_FLAGS` | No--Optional = | Microsoft C Flags to > use with for a cl commands for this module | Normally not used in INF fil= es. 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 C= omponent (module) Types for the default FV extension. > | > -| `SOURCE_FV` | No--Optional = | Word > | If present, the variable is set at the beginning of the generated makef= ile > | > -| `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 th= e VERSION section of the FFS. > | > - > -The following table lists the available `COMPONENT_TYPE` values supporte= d 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 me= ta-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 proces= sed (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 sh= ould 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 pr= eparing the platform for the PEI Phase. Since there are no standard > services defined for SEC, modules of this type follow the same rules as m= odules 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 PE= I 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] entr= y: `SHADOW =3D 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 ex= ecute 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 s= ervices 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 call= ed and either physical mode or virtual mode after > SetVirtualAddressMap() is called. This module type is only available to I= PF 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 thes= e 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 UE= FI 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 subdirec= tories > -of the component. All directory names are relative to the location of th= e INF > -file. Macros are allowed in the source file path. For EDK builds, each f= ile is > -added to the macro of `$(INC_DEPS)`, which can be used in a makefile dep= endency > -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 doe= s > -provide a method for specifying binary files in the `[sources]` section.= The > -following lists the mapping of EDK specific binary file types to EFI sec= tions. > - > -**_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 th= e > -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 e= ach > -library, `{LibName}`, found, the `{LibName}` is added to the LIBS defini= tion in > -the output makefile: > - > -`LIBS =3D $(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 speci= fied, > -the following line is written to the component's makefile. > - > -`INC =3D $(INC) -I $(SOURCE_DIR)\{path}` > - > -The path must be absolute, however the use of the global variable, EDK_S= OURCE > -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" t= o > -restrict processing based on the processor name. The section data is sim= ply > -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. Ref= er to > -make command reference for your tool chains. > - > -The following is an example of the EDK `[nmake]` section. > - > -```ini > -[nmake.common] > - IMAGE_ENTRY_POINT =3D DiskIoDriverEntryPoint > -``` > diff --git a/appendix_a_edk_inf_file_specification/a2_edk_file_specificat= ion.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 @@ > - > - > -## 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 i= n order > -to support building on UNIX style operating systems. > -********** > - > -A section terminates with either another section definition or the end o= f the > -file. > - > -#### Summary > - > -Component EDK INF description > - > -#### Prototype > - > -```c > - ::=3D [
] > - > - > - [] > - [] > - [] > -``` > - > -### 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 > -
::=3D ["#"] "/*++" > - [] > - [] > - [] > - [] > - ["#"] "--*/" > - ::=3D ["#"] "Abstract:" > - [["#"] ]* > - ["#"] > - ::=3D ["#"] "Module Name:" > - [["#"] + ]+ > - ["#"] > - ::=3D [["#"] "Copyright (c) "," ]+ = ["#"] > - > - ::=3D [["#"] ]+ > - ["#"] > -``` > - > -#### 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 sec= tion. > - > -This is a required section. > - > -The define sections defines symbols that describe the component. Some it= ems are > -emitted to the output makefile. > - > -The `FILE_GUID` is required for all EDK components that are not librarie= s. This > -guid is used to build the FW volume file list used by build tools to gen= erate > -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` defi= nition > -is case sensitive. The default FV extension can be overridden by definin= g 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 st= atic > -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 > - ::=3D "[defines" [] "]" + > - ::=3D ["," "defines" ]* > - ::=3D "." ["." ] > - ::=3D {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} > - ::=3D {} {"$(PLATFORM)") {"platform"} > - ::=3D "BASE_NAME" "=3D" > - ["COMPONENT_TYPE" "=3D" ] > - ["FILE_GUID" "=3D" ] > - ["EDK_RELEASE_VERSION" "=3D" "0x00020000" ] > - ["MAKEFILE_NAME" "=3D" ] > - ["CUSTOM_MAKEFILE" "=3D" ] > - ["BUILD_NUMBER" "=3D" {1,4} ] > - ["BUILD_TYPE" "=3D" ] > - ["FFS_EXT" "=3D" ] > - ["FV_EXT" "=3D" ] > - ["SOURCE_FV" "=3D" ] > - ["PACKAGE" "=3D" "CompressPEIM" ] > - ["VERSION_NUMBER" "=3D" {1,4} ] > - ["VERSION_STRING" "=3D" ] > - ["GENERIC_CAPSULE_FILE_PATH" "=3D" ] > - ["MICROCODE_ALIGNMENT" "=3D" ] > - ["MICROCODE_FILE_PATH" "=3D" ] > - ["PLATFORM_BDS_FILE_PATH" "=3D" ] > - ["RESTRICTED_BDS_FILE_PATH" "=3D" ] > - ::=3D [] ["." ] > - ::=3D > - ::=3D {"MAKEFILE"} {"CUSTOM_MAKEFILE"} {} > - ::=3D [ "\"] > - ::=3D [{ "\"} {"..\"}]+ > - ::=3D {"$(" ")"} > - {"$(EFI_SOURCE)"} {"$(EDK_SOURCE)"} > - ::=3D {} > - {"$(EFI_APRIORI_GUID)"} > - {"$(EFI_ACPI_TABLE_STORAGE_GUID)"} > - {"$(EFI_DEFAULT_BMP_LOGO_GUID)"} > - {"$(EFI_PEI_APRIORI_FILE_NAME_GUID)"} > - ::=3D {"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"} > - ::=3D > -``` > - > -#### Example (EDK Driver) > - > -```ini > -[Defines] > - BASE_NAME =3D DiskIo > - FILE_GUID =3D CA261A26-7718-4b9b-8A07-5178B1AE3A02 > - COMPONENT_TYPE =3D BS_DRIVER > -``` > - > -#### Example (EDK Library) > - > -```ini > -[Defines] > - BASE_NAME =3D WinNtLib > - COMPONENT_TYPE =3D LIBRARY > -``` > - > -### A.2.3 [includes] Section > - > -#### Summary > - > -Defines the optional "includes paths" for EDK INF files only. These sect= ions > -should never be used in EDK II INF files. These sections are used to def= ine the > -include paths for compiling the component source files. Valid sections f= or EDK > -include the `[includes.$(PROCESSOR).$(PLATFORM)]`, `[includes.$(PROCESSO= R)]`, > -and `[includes.common]` sections. > - > -********** > -**NOTE**: EDK uses both "include" and "includes" section header types. T= hese > -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 wil= l be > -added to the `$(INC)` macro using the `/FI` (Microsoft) or `-include` (G= CC) > -switch. This is an optional section. > - > -#### Prototype > - > -```c > - ::=3D "[include" ["s"] [] ']" > - + > - ::=3D ["," "include" ["s"]? ]* > - ::=3D [] [] [] > - ::=3D "." > - ::=3D {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} {} > - ::=3D "." {"$(PROCESSOR)"} {"$(" ")"} > - ::=3D "." {"Platform") {"nt32"} {"$(PLATFORM)"} > - ::=3D {} {} > - ::=3D ["\" ]+ > - ::=3D {"$(EDK_SOURCE)"} {"$(EFI_SOURCE)"} {"$(BUILD_DIR)"} > - {"$(SOURCE_DIR)"} > - ::=3D ["..\"]+ {".."} {} > -``` > - > -#### 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 com= ponent's > -makefile. All libraries listed in the `[libraries.common]`, > -`[libraries.$(PROCESSOR)]`, and `[libraries.$(PROCESSOR).$(PLATFORM)]` s= ections > -are added to the LIBS definition as either `$(LIB_DIR)\LibName` or > -`$(PROCESSOR)\LibName`. The libraries are specified without path informa= tion. > - > -The standard Macro Definitions are not permitted in this section. > - > -This is an optional section. > - > -#### Prototype > - > -```c > - ::=3D "[libraries" [] ']" + > - ::=3D "." ["." ] > - ::=3D ["," ["." ]] > - ["," "libraries." ]* > - ::=3D {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} > - {"platform"} {"nt32"} {"$(PROCESSOR)"} > - ::=3D {"platform"} {"$(PLATFORM)"} {} > - ::=3D > -``` > - > -#### Example > - > -```ini > -[Libraries.common] > - EfiProtocolLib > - EfiDriverLib > -``` > - > -### A.2.5 [nmake] Section > - > -#### Summary > - > -Defines the [nmake] section tag for EDK INF files. These sections are us= ed 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 spe= cified > -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_IN= CLUDE` > -line is usually used to clear any flags that might have been set by the > -Microsoft tool chain setup scripts, therefore no `` 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 > - ::=3D "[nmake" [] ']" > - + > - ::=3D [] ["," "nmake" ]* > - ::=3D "." > - ::=3D "." > - ::=3D {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} > - ::=3D [] [] [] [] [] [] [= ] [] > - ::=3D "IMAGE_ENTRY_POINT" "=3D" > - ::=3D "DPX_SOURCE" "=3D" > - ::=3D "C_STD_INCLUDE" "=3D" [] > - ::=3D "C_PROJ_FLAGS" "=3D" > - ::=3D "ASM_PROJ_FLAGS" "=3D" > - ::=3D "LIB_STD_FLAGS" "=3D" > - ::=3D ["EBC_C_STD_FLAGS" "=3D" ] > - ["EBC_LIB_STD_FLAGS" "=3D" ] > - ::=3D "=3D" {} {} > - ::=3D 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 =3D > - IMAGE_ENTRY_POINT=3DWatchdogTimerDriverInitialize > - DPX_SOURCE=3DWatchDogTimer.dxs > - > -[nmake.common] > - C_FLAGS =3D $(C_FLAGS) /D EDKII_GLUE_LIBRARY_IMPLEMENTATION > - LIB_STD_FLAGS =3D $(LIB_STD_FLAGS) /IGNORE:4006 /IGNORE:4221 > - > -[nmake.ia32] > - C_FLAGS =3D $(C_FLAGS) /D MDE_CPU_IA32 > - > -[nmake.x64] > - C_FLAGS =3D $(C_FLAGS) /D MDE_CPU_X64 > - > -[nmake.ipf] > - C_FLAGS =3D $(C_FLAGS) /D MDE_CPU_IPF > - > -[nmake.ebc] > - EBC_C_STD_FLAGS =3D $(EBC_C_STD_FLAGS) /D EDKII_GLUE_LIBRARY_IMPLEME= NTATION > - EBC_LIB_STD_FLAGS =3D $(EBC_LIB_STD_FLAGS) /IGNORE:4006 /IGNORE:4221 > - EBC_C_STD_FLAGS =3D $(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 processo= r. > -Example sources sections are listed below. The parsing utility creates a > -directory path for each file (`$(DEST_DIR)...\MyFile.c`), and looks up t= he > -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 t= o ACPI > -tables, this value wil be ignored by EDK II build tools. > - > -#### Prototype > - > -```c > - ::=3D "[source" ["s"] [] "]" > - []* []+ > - ::=3D ["," "sources" ]* > - ::=3D if (COMPONENT_TYPE defined in defines): > - "." [] else: > - "." > - ::=3D if (COMPONENT_TYPE defined in defines): ["," > - ]* else: > - ["|" ]* > - ::=3D {"IA32"} {"X64"} {"IPF"} {"Common"} > - ::=3D "." {"$(PLATFORM)"} {"$(PROCESSOR)"} {} > - ::=3D ["DEFINE" "=3D" [] ]* > - ["TABLE_NAME" "=3D" ] > - ::=3D ["|" ] > - ::=3D {"MSFT"} {"GCC"} {"INTEL"} {"*"} > - ::=3D "." > - ::=3D [ {"\"} {"/"}] [ {"\"} {"/"}]+ > -``` > - > -#### 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_dr= iver_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_l= ibrary_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_bi= nary_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 >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel