2. Add MODULE_UNI_FILE file that contains the localized Abstract and Description of a module. a. Addresses an information gap between INF files and the UEFI Distribution Packaging Specification XML schema b. There will be an associated update to UPT in BaseTools to consume MODULE_UNI_FILE and associated UNI file during UDP creation that performs the INF -> XML conversion. c. There will be an associated update to UPT in BaseTools to produce MODULE_UNI_FILE and associated UNI file during UDP installation that performs the XML -> INF conversion. 3. Add Module Extra UNI file that provides the localized Name of a module. a. [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a module to specify extra files not listed in [Sources] or [Binaries] sections to be added to a UDP without having to list the files in the UPT package information data file. b. There will be an associated update to UPT in BaseTools to package up files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation. c. UNI file contains localized name of a module to go along with the localized Abstract and Description from the MODULE_UNI_FILE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zeng, Star <star.zeng@intel.com> Reviewed-by: Gao, Liming <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15967 6f19259b-4bc3-4df7-8a09-765794883524
40 lines
7.9 KiB
Plaintext
40 lines
7.9 KiB
Plaintext
// /** @file
|
|
// This driver initializes and installs the Data Hub protocol.
|
|
//
|
|
// The data hub is a volatile database that is intended as the major focus for the accumulation of
|
|
// manageability data.T he hub is fed by "producers" with chunks of data in a defined format.
|
|
// Consumers may then extract the data in temporal "log" order.As an example, progress codes might
|
|
// be recorded in the data hub for future processing.Ot her data contributed to the data hub might
|
|
// include, for example, statistics on enumerated items such as memory, add-in buses, and add-in
|
|
// cards and data on errors encountered during boot (for example, the system did not boot off the
|
|
// network because the cable was not plugged in).
|
|
// Some classes of data have defined formats.For example, the amount of memory in the system is
|
|
// reported in a standard format so that consumers can be written to extract the data.O ther data is
|
|
// system specific.For example, additional detail on errors might be specific to the driver that
|
|
// discovered the error.The consumer might be a driver that tabularizes data from the data hub,
|
|
// providing a mechanism for the raw data to be made available to the OS for post-processing by
|
|
// OS-based applications.
|
|
// The intent of the data hub is for drivers that enumerate and configure parts of the system to report
|
|
// their discoveries to the data hub.This data can then be extracted by other drivers that report those
|
|
// discoveries using standard manageability interfaces such as SMBIOS and Intelligent Platform
|
|
// Management Interface (IPMI).The alternative to a data-hub-like architecture is to require all
|
|
// drivers to be aware of all reporting formats.
|
|
// For more information, please ref http://www.intel.com/technology/framework/
|
|
//
|
|
// Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
|
|
//
|
|
// 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.
|
|
//
|
|
// **/
|
|
|
|
|
|
#string STR_MODULE_ABSTRACT #language en-US "Initializes and installs the Data Hub protocol"
|
|
|
|
#string STR_MODULE_DESCRIPTION #language en-US "The data hub is a volatile database that is intended as the major focus for the accumulation of manageability data. The hub is fed by \"producers\" with chunks of data in a defined format. Consumers may then extract the data in a temporal \"log\" order. As an example, progress codes might be recorded in the data hub for future processing. For example, other data contributed to the data hub might include, statistics on enumerated items such as memory, add-in buses, and add-in cards, and data on errors encountered during boot (such as, the system did not boot off the network because the cable was not plugged in). Some classes of data have defined formats. For example, the amount of memory in the system is reported in a standard format so that consumers can be written to extract the data. Other data is system specific. For example, additional detail on errors might be specific to the driver that discovered the error. The consumer might be a driver that tabularizes data from the data hub, providing a mechanism for the raw data to be made available to the OS for post-processing by OS-based applications. The intent of the data hub is for drivers that enumerate and configure parts of the system to report their discoveries to the data hub. This data can then be extracted by other drivers that report those discoveries using standard manageability interfaces such as SMBIOS and Intelligent Platform Management Interface (IPMI). The alternative to a data-hub-like architecture is to require all drivers to be aware of all reporting formats. For more information, refer to http://www.intel.com/technology/framework/ ."
|
|
|