From 64b2609fcff9d6412eea4c74c8e74bed33dc3235 Mon Sep 17 00:00:00 2001 From: lgao4 Date: Tue, 10 Apr 2012 07:18:20 +0000 Subject: Sync BaseTools Trunk (version r2518) to EDKII main trunk. Signed-off-by: Liming Gao git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13178 6f19259b-4bc3-4df7-8a09-765794883524 --- BaseTools/Conf/XMLSchema/FarManifest.xsd | 174 ----- .../Conf/XMLSchema/FrameworkDataAttributes.xsd | 180 ----- BaseTools/Conf/XMLSchema/FrameworkDataElements.xsd | 728 --------------------- BaseTools/Conf/XMLSchema/FrameworkDataTypes.xsd | 581 ---------------- BaseTools/Conf/XMLSchema/FrameworkHeaders.xsd | 93 --- BaseTools/Conf/XMLSchema/NamingConvention.xsd | 186 ------ BaseTools/Conf/XMLSchema/SurfaceArea.xsd | 82 --- BaseTools/Conf/XMLSchema/SurfaceArea.xsdconfig | 16 - BaseTools/Conf/XMLSchema/WorkspaceContent.xsd | 409 ------------ 9 files changed, 2449 deletions(-) delete mode 100644 BaseTools/Conf/XMLSchema/FarManifest.xsd delete mode 100644 BaseTools/Conf/XMLSchema/FrameworkDataAttributes.xsd delete mode 100644 BaseTools/Conf/XMLSchema/FrameworkDataElements.xsd delete mode 100644 BaseTools/Conf/XMLSchema/FrameworkDataTypes.xsd delete mode 100644 BaseTools/Conf/XMLSchema/FrameworkHeaders.xsd delete mode 100644 BaseTools/Conf/XMLSchema/NamingConvention.xsd delete mode 100644 BaseTools/Conf/XMLSchema/SurfaceArea.xsd delete mode 100644 BaseTools/Conf/XMLSchema/SurfaceArea.xsdconfig delete mode 100644 BaseTools/Conf/XMLSchema/WorkspaceContent.xsd (limited to 'BaseTools/Conf/XMLSchema') diff --git a/BaseTools/Conf/XMLSchema/FarManifest.xsd b/BaseTools/Conf/XMLSchema/FarManifest.xsd deleted file mode 100644 index 6e8c34ae9a..0000000000 --- a/BaseTools/Conf/XMLSchema/FarManifest.xsd +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - - The Framework Archive File Format is defined as a Java Archive file, with a special xml file called FrameworkArchiveManifest.xml at the top of the archive. The FrameworkArchiveManifest.xml must be an instance of this schema. - - - - - - This schema defines the Framework Archive Manifest. - - - - - - - - - The list of packages in this FAR. - - - - - - - Extra contents that are not part of any Package. These file paths are WORKSPACE relative. If a file exists in the workspace at this location, then the user should be asked whether to overwrite. When the user removes the far, these should be removed also, unless they have been modified (per md5sum). - - - - - - - - - - - - - - - - - - - - - This is the name of the .spd or file that describes the package. It must exist in the directory identified by DefaultPath. - - - - - - - - - This is the default installation location within the workspace. This also serves as the location within the far itself of the package root. The Contents of the pacakage will be found there. The user may choose some other location within the workspace to install the package, as long as it does not overlap a package that is already installed. - - - - - - - This is the list of files that belong to the package. They are specified by relative path from the root of the pacakge. - - - - - - - - - - - - The FarFilename is used to build up the Contents list. It has an md5sum attribute for keeping track of whether the file is changed after it is installed. The Md5sum can also be used to check the integrity of a far before it is installed into the workspace. - - - - - - - The purpose of this element is to allow Guids to be assigned to or used by other elements in the schema. - - - - - - - This tag allows us to specify a tree of files all having a common root. All the files specified are relative to that common root. - - - - - - - - - - - Definitions and rules for creating, installing, updating and removing fars within the workspace. - - - 1. A module m is said to depend upon a package p, iff there exists a tuple (PackageGuid, PackageVerion) in the set m->PackageDependencies for which p->Guid==PackageGuid, and if PackageVersion is not empty, then p->Version== PackageVersion. - - - 2. A far f is said to depend on a far g, iff there is a module in a package in f that depends on a package in g. - - - 3. A far f is said to depend on a package p, iff there is a module m contained in f that depends on p. - - - 4. A far f may be installed into the workspace w, iff for each module m in f, m's dependencies are met by the packages in w or f. - - - a. It is supported to "partially" install a far. A partial installation of a far means that 1 or more packages are installed into the workspace from the far. For each package p in f, p's dependencies must be satisfied by a package in the workspace. - - - 5. A far f may be removed from the workspace w, iff for each module m in w, and for each package p in f, m does not depend on p. - - - a. It is supported to "partially" remove a far. In this case, one or more of the packages in the far can be removed, provided that for each package p in the workspace w, there does not exist a module m such that m depends on p. - - - 6. When installing a far f into workspace w, for each package p in f, allow the user to install in p's default location, or choose a new location l (which must be unoccupied) within the workspace. Record this location l in the database. Each package p in f will be recorded in the database, associated with the GUID of f, as well as the actual install location l. (So we will know which far each package belongs to.) - - - 7. When installing a far f into workspace w, if there exists a package p in w, and p is in f, then the user must be prompted to choose a location that does not collide with the location of p in workspace w. We will end up with two instances of p in w at two distinct locations. Alternately, the user may elect to partially install the far, leaving out the redundant package. - - - 8. A far f may replace a far g in the workspace w, iff for each module m contained in w, if m depends on a package p, and p is only contained in g, then there must exist a package q in f, such that m depends on q. The net effect is that g is removed and f is installed, in one operation. The normal rules for installing f still apply--the dependencies of the modules of f must be satisfied. After the replacement, it must be the case that all the modules dependencies in the workspace are satisfied. Note that it is possible to backrev a package in this way. - - - (If we find that the replace is not permitted, then the user may install f and keep g. Next, he could _port_ every module m in w that depends on g, to f and eventually remove g.) - - - 9. A special case of the above rule is that a far f may be reinstalled into the workspace. (This would allow the user to get a fresh copy, or change the location in the workspace where one or more of the packages of f are installed.) - - - 10. When a far f is removed from the workspace w, for each package p in f, we will remove p from w. - - - 11. If a package p belongs to a far f, then it is legal to remove p from the workspace w iff, there does not exist a module m in w such that m depends on p. - - - 12. When a far f is removed from the workspace, the we will remove all the files in f from the workspace tree. If a file has been modified from the original as installed from the far (per md5sum) then the user should be asked if he is "sure" he wants to remove it. - - - 13. When a far is created, a GUID is generated and assigned to the far. If a far is created from the same components at a later time, it would have a different GUID. - - - 14. If a package p is marked with p->RePackage==false, then p may not be added to a far. - - - 15. A far f is identical to a far g, iff f->Guid == g->Guid. - - - 17. A far f may be installed into the workspace w, iff there is no far g in w such that f->Guid==g->Guid. In that case, it is called "updating" the far in the workspace. The user may select some subset of packages to reinstall or update, to ensure that the files in the workspace are correct. - - - diff --git a/BaseTools/Conf/XMLSchema/FrameworkDataAttributes.xsd b/BaseTools/Conf/XMLSchema/FrameworkDataAttributes.xsd deleted file mode 100644 index eeb48d9a8a..0000000000 --- a/BaseTools/Conf/XMLSchema/FrameworkDataAttributes.xsd +++ /dev/null @@ -1,180 +0,0 @@ - - - - - This schema defines EFI and Framework Attribute. Only attributeGroups are specified in this file. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/BaseTools/Conf/XMLSchema/FrameworkDataElements.xsd b/BaseTools/Conf/XMLSchema/FrameworkDataElements.xsd deleted file mode 100644 index e094c1b626..0000000000 --- a/BaseTools/Conf/XMLSchema/FrameworkDataElements.xsd +++ /dev/null @@ -1,728 +0,0 @@ - - - - - This schema defines EFI and Framework Data Elements - - - - - - - Abstract is valid for all Description Files - This section is required. This is a single sentence to describe the module and will be used in sample files as the abstract data in the header comment section. - - - - - BootModes is valid for all Description Files - This is a list of BootModes Supported by the Module - - - - - - - - - - - - - - - - - - This is a list of DataHubRecord elements. - - - - - - - - - - - - - - - - - - The default setting of a PCD entry. - - - - - - - - - - This section is used to describe the DXE or PEI Dependency code - - - - - - - - - - - This section is required for new modules and libraries and must contain more information than the Abstract. - - - - - Multiple Filenames may be specified, and they may also be scoped to a specific Architecture. - - - - - - - - - - - - - - - - - - - This is a list of MSA Events - - - - - - - - - - - - - - - - - - - - - Module has an event that is waiting to be signaled. Event is named by GUID. - - - - - - - - - - - - - - - - - - - - - This is a child of MSA files. - - - - - - - - - - - - Driver Module - - - - - - - Library Module - - - - - - - Allow multiple entries for DriverBinding, ComponentName, DriverConfig and DriverDiag elements. For ComponentName, DriverConfig and/or DriverDiag - you must have a 1:1 mapping to DriverBinding if the element is defined. - Permit User Defined Extern Tags - - - - - - - - - Module Call Backs - - - - - - - - - - - - - - Describe the valid content of a filename This should extend PathAndFilename - Variable names not allowed here! - - - - - - - - - - - - This is a list of Filenames - - - - - - - - - - This is a child of PackageSurfaceArea (SPD) - - - - - - - - - - - - - - - - - - - - - - Describe the valid content of a GUID element in and MSA file. - - - - - - - - - - - - - - - Describe the list of a HiiPackage elements - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Used in MSA files. This defines what class of library is being supported = produced (library module) or consumed by a module. - - - - - - - - - - - - - - - - - - - - - - - - - - - - This section defines what Classes of Library that this library supports. A Library may belong to multiple different library classes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Describe the valid EFI Phase that the Module is designed to execute under. - - - - - - MsaFiles is a child of Surface Area Package Description (SPD) files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This tag is used in the Module Surface Area Description File (MSA) to track package dependencies for a module. - Attributes to PackageName include Required: Usage PackageGuid PackageVesion, Optional: FeatureFlag - - - - - - - - - - - - - - PackageHeaders is a child of PackageSurfaceArea (SPD) - - - - - - - - - - - - - - - - - - - This tag is used in the Framework Package Database File to track all packages (SPD files) installed in a workspace. (Database) - - - - - - - - - - - - - - - - - - Child of Module Surface Area Description (MSA) - - - - - - - - - - - - - - - - - - - - - - PcdDeclaratins is a child of Package Surface Area Description (SPD) - - - - - - - - - - - - - - - - - - - - - - - - This tag is used in the Framework Package Database File to track all DISTRIBUTION packages (FAR files) installed in a workspace. (Database) - - - - - - - - - - PpiDeclarations is a child of PackageSurfaceArea (SPD) - - - - - - - - - - - - - - - - - - - Provide for one or more Ppi or PpiNotify sections. - - - - - - - - - - - - - - - - - - - - - - - - - - - ProtocolDeclarations is a child of PackageSurfaceArea (SPD) - - - - - - - - - - - - - - - - - - - If either Protocol or ProtocolNotify sections are needed, one or more of them should be specified within this section - - - - - - - - - - - - - - - - - - - - - - - - - - - Multiple Filenames may be specified, and they may also be scoped to a specific Architecture. - - - - - - - - - - This is list of System Table elements. - - - - - - - - - - - - - - - - - - - - - - - - - - - An MSA FILE list of EFI Variables described by string pair. - - - - - - This is an EFI Variable Entry - - - - - - - - - - - - - - - diff --git a/BaseTools/Conf/XMLSchema/FrameworkDataTypes.xsd b/BaseTools/Conf/XMLSchema/FrameworkDataTypes.xsd deleted file mode 100644 index 9a46a02a2e..0000000000 --- a/BaseTools/Conf/XMLSchema/FrameworkDataTypes.xsd +++ /dev/null @@ -1,581 +0,0 @@ - - - - - This schema defines EFI and Framework Data Types. Only simpleType are specified in this file. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/BaseTools/Conf/XMLSchema/FrameworkHeaders.xsd b/BaseTools/Conf/XMLSchema/FrameworkHeaders.xsd deleted file mode 100644 index e2745af378..0000000000 --- a/BaseTools/Conf/XMLSchema/FrameworkHeaders.xsd +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - - This is the header for the Framework Package Database (DB) file. - The Guid MUST change if backward compatibility breaks caused by a new release of XML Schema. - The Version will change if a minor change to XML Schema has been made, but backward compatiblity is maintained. - - - - - - - - - - - - - - - - - This is the header for the Framework Archive Manifest file. - - - - - - - - - - - - - - - - - This header is for the Module Surface Area Description (MSA) files - The Guid MUST change if the Module changes break backward compatibility. - The Version MUST change if the Module changes, however, backward compatiblity is maintained. - - - - - - - - - - - - - - - - - - This head is for the Surface Area Package Description file (SPD) - The Guid MUST change when the contents of the file undergo MAJOR FUNCTIONALITY changes. - The Version MUST change when the contents of the file undergo MINOR FUNCTIONALITY changes. - - - - - - - - - - - - - - - diff --git a/BaseTools/Conf/XMLSchema/NamingConvention.xsd b/BaseTools/Conf/XMLSchema/NamingConvention.xsd deleted file mode 100644 index 8a76639777..0000000000 --- a/BaseTools/Conf/XMLSchema/NamingConvention.xsd +++ /dev/null @@ -1,186 +0,0 @@ - - - - - This schema defines various data types and naming conventions including: base name, filename and directory naming conventions. These are all simple data types. - - - - C_Names must start with either an underscore (_) character followed by one or more alpha characters, followed by any combination of underscore or alphanumeric characters. - - - - - - - - This defines what a Filename is: Alphanumeric characters and optional underscore (_) or dash (-) characters, followed by a optional dot and more alphanumeric characters. - - - - - - - - The GUID data was a union of GuidType1 and GuidType2; standardizing on GuidType2. - - - - - - This defines the minimum specification for a GUID Array which is 8 Hex Digits - 4 Hex Digits - 4 Hex Digits - 8 Hex Bytes, the last 16 Hex Digits can be enclosed in sqiggle {} brackets. - - - - - - - - A GUID must contain five different Hexadecimal character sets that are separated by a dash (-) character. - - - - - - - - Define a Hex 64 Bit Value to be 0x[a-f0-9]{16} - - - - - - - - Define a Hex Address, 0x[a-fA-F0-9]{1,16} - - - - - - - - Define a Hex Byte Value to be 0x[a-f0-9]{2} - - - - - - - - Define a Hex Value to be 0x[a-f0-9]+ - - - - - - - - Define a Hex Diget to be 0x[a-f0-9] - - - - - - - - Define a Hex Double Word Value to be 0x[a-f0-9]{8} - - - - - - - - Define a Hex Word Value to be 0x[a-f0-9]{4} - - - - - - - - - - - - - - - - - - - This describes the normal text of a paragraph that can be used in a license or description tag. - - - - - - Naming convention for a path and file name - - - - - - Limit Polarity vaild values to 0 and 1 - - - - - - - - This data type requires two or more words - - - - - - - - This data type is used for ToolCommand, ToolChainFamily and TagName. - - - - - - - - Definition of a UpperCase Name, which can be any combination of upper case characters followed by zero or more underscore and/or uppercase alphanumeric characters - - - - - - - - Definition of a Version Number, which is one or more strings of decimal digits separated by dots. - - The algorithm to compare two versions A and B is as follows. if A==B, then A is the same version as B. Otherwise, say A is a1.a2.a3...an and B is b1.b2.b3...bn. For the first pair (ai, bi), for i less than n and i less than m, where ai is not equal to bi, if ai is less than bi, then A is less than B. If ai is greater than bi, then A is greater than B. - - - - - - - - - Define Zero as a vaild value - - - - - - diff --git a/BaseTools/Conf/XMLSchema/SurfaceArea.xsd b/BaseTools/Conf/XMLSchema/SurfaceArea.xsd deleted file mode 100644 index c941be81e7..0000000000 --- a/BaseTools/Conf/XMLSchema/SurfaceArea.xsd +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - - This describes the valid content of a FrameworkDatabase (DB) File. - - - - - - - - - - - - - This describes the valid content for a Module Surface Area Description (MSA) file. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This describes the valid content for a Package Surface Area Description (SPD) file. - - - - - - - - - - - - - - - - - - - diff --git a/BaseTools/Conf/XMLSchema/SurfaceArea.xsdconfig b/BaseTools/Conf/XMLSchema/SurfaceArea.xsdconfig deleted file mode 100644 index 5d86b98fe7..0000000000 --- a/BaseTools/Conf/XMLSchema/SurfaceArea.xsdconfig +++ /dev/null @@ -1,16 +0,0 @@ - - - - - org.tianocore - - - diff --git a/BaseTools/Conf/XMLSchema/WorkspaceContent.xsd b/BaseTools/Conf/XMLSchema/WorkspaceContent.xsd deleted file mode 100644 index 1c9491a5e6..0000000000 --- a/BaseTools/Conf/XMLSchema/WorkspaceContent.xsd +++ /dev/null @@ -1,409 +0,0 @@ - - - - - This document covers the - WorkspaceContent.xml file that tracks what has been installed into an EDK - II development WORKSPACE. - - - - This file describes the distributions, - packages, stand-alone (non-package) modules and miscellaneous files that - have been installed in THIS WORKSPACE. Additionally, any tools that are - installed as part of a distribution are tracked (tools are not required - to be installed within a WORKSPACE.) - - - - - - This section tracks required - information about this WORKSPACE. - - - - - The list of UEFI/PI distribution - packages that have been installed in this WORKSPACE. - - - - - - - - - - - - - This User Interface Name can be - entered during initialization of a WORKSPACE to permit a developer - to uniquely identify a WORKSPACE. - This value can be used by report - generators. - - - - - When the WORKSPACE is first - initialized, this is the absolute path to the WORKSPACE. If the - user moves or re-names the directory, the RmPkg tool will need to - verify the content of this WORKSPACE before removing any content. - - - - - - The date and time of the last - Package Installation or Removal. The format is: - YYYY-MM-DDThh:mm:ss, for example: 2001-01-31T13:30:00 (note the T - character separator between the calendar date and the time. - - - - - - - - - - - - - - - - - - - The User Interface Name of - the module. - - - - - - - The BaseName is - used to create files and folders during a build, and - is used by packaging tools as a keyword to create - the INF file. - - - - - - - - - This is the GUID of the - module. Backward compatible versions of a module can use the - same GUID, however the version attribute must be changed - (incrementally.) Non-backward compatible versions of a - module must also provide a new GUID, while resetting the - version attribute is optional. - - - - - This is the WORKSPACE - relative path that the Module was installed in. - - - - - - This is filename of the - INF file created in the InstalledFolder (listed above) - during installation. - - - - - - - - - - - - - - - The User Interface Name of the - distribution. - - - - - - - This is the actual - BaseName used during the installation. Since users may - change the Distribution Package's default BaseName (used - to create the PKG and MANIFEST files) this is the real - name used to create the files. - - - - - - - - - This is the GUID of the - distribution, backward compatible versions of a distribution can - use the same GUID, however the version attribute must be changed - (incrementally.) Non-backward compatible versions of a - distribution must also provide a new GUID, while resetting the - version attribute is optional. - - - - - This is the filename of the XML - distribution package surface area (PKG) file that was stored in - the Conf/Pkgs folder of the WORKSPACE for this distribution - package. - - - - - This is the filename of the - distribution package manifest (.manifest) file that was created - and stored in the Conf/Pkgs folder of the WORKSPACE for this - distribution package. The InstallPkg tool must create this file - using the extracted locations of the content zip file (or, - alternatively, the user can create the file by redirecting the - output of the zip -Tv Contents.zip.) - - - - - - This section tracks information - and content that is not associated with either packages or - modules, or is not required for building packages or modules. - - - - - - If set to true, all content - within this distribution package should NOT be - modified. - - - - - If set to true, then the - content can be repackaged into another distribution - package. - - - - - If set to true, then either - the distribution or one of its packages has a user extensions - section that modified the tools_def.txt file. - - - - - - This is used to identify a - distribution that provides tools that may or may not be - installed in a WORKSPACE. - - - - - This is used to identify a - distribution that provides miscellaneous files that must be - installed in a WORKSPACE. - - - - - This is used to identify a - distribution that has a UserExtensions section at the - Distribution, Package or Module level that uses an Identifier - other than BuildOptions, ToolsDef or DistributionPackage. - - - - - - - - This section tracks individual - packages (collections of related items.) Each package listed in - this section must have a DEC file associated with it. - - - - - - - - - - The User Interface - Name of the package. - - - - - - - The BaseName - is used to create files and folders during a - build, and is used by packaging tools as a - keyword to create the DEC file. - - - - - - - - - - This is the GUID of - the package, backward compatible versions of a package - can use the same GUID, however the version attribute - must be changed (incrementally.) Non-backward - compatible versions of a package must also provide a - new GUID, while resetting the version attribute is - optional. - - - - - This is used to - track the actual installation location, relative to - the WORKSPACE. During an installation, the user may be - presented with an option to relocate package content - from the ZIP portion of the archive into a different - location. - Any installation tools must modify - this value if the location is different from the - default location. - Any removal tools must check this - value to locate correctly, the items that will be - removed. - - - - - This is the filename - of the package declaration (DEC) filename created - during installation in the InstalledFolder listed - above. - - - - - This section is used - to track the actual installation location, relative to - the WORKSPACE. Every module that is part of this - package must be listed here. During an installation, - the user may be presented with an option to relocate - module content from the ZIP portion of the archive - into a different location, the installation tools must - modify this value if the location is different from - the default location. Any removal tools must check - this value to locate correctly, the items that will be - removed. - The name of any INF - files that were created during the installation of a - distribution must also be listed in this section. - - - - - - - - - - - - This section is used to record - distribution packages that contain modules that are not part of a - package. Modules that are part of packages are listed under the - Package element of the PackageList section. - Module only distribution will - typically be for binary only modules, like the enhanced FAT - driver. - - - - - - - - - - - - - - - - - - - - - A Registry format GUID must contain - five different Hexadecimal character sets that are separated by a dash - (-) character. - - - - - - - -- cgit v1.2.3