}\r
\r
/**\r
- Create a Legacy Boot Event.\r
-\r
- Tiano extended the CreateEvent Type enum to add a legacy boot event type.\r
- This was bad as Tiano did not own the enum. In UEFI 2.0 CreateEventEx was\r
- added and now it's possible to not voilate the UEFI specification by\r
- declaring a GUID for the legacy boot event class. This library supports\r
- the EDK/EFI 1.10 form and EDK II/UEFI 2.0 form and allows common code to\r
- work both ways.\r
+ Creates an EFI event in the Legacy Boot Event Group.\r
+\r
+ Prior to UEFI 2.0 this was done via a non blessed UEFI extensions and this library\r
+ abstracts the implementation mechanism of this event from the caller. This function\r
+ abstracts the creation of the Legacy Boot Event. The Framework moved from a proprietary\r
+ to UEFI 2.0 based mechanism. This library abstracts the caller from how this event\r
+ is created to prevent to code form having to change with the version of the\r
+ specification supported.\r
+ If LegacyBootEvent is NULL, then ASSERT().\r
\r
@param LegacyBootEvent Returns the EFI event returned from gBS->CreateEvent(Ex).\r
\r
}\r
\r
/**\r
- Create a "Ready to Boot" Event.\r
+ Create an EFI event in the Ready To Boot Event Group.\r
+\r
+ Prior to UEFI 2.0 this was done via a non-standard UEFI extension, and this library\r
+ abstracts the implementation mechanism of this event from the caller. \r
+ This function abstracts the creation of the Ready to Boot Event. The Framework \r
+ moved from a proprietary to UEFI 2.0-based mechanism. This library abstracts \r
+ the caller from how this event is created to prevent the code form having to \r
+ change with the version of the specification supported.\r
+ If ReadyToBootEvent is NULL, then ASSERT().\r
\r
- Tiano extended the CreateEvent Type enum to add a ready to boot event type.\r
- This was bad as Tiano did not own the enum. In UEFI 2.0 CreateEventEx was\r
- added and now it's possible to not voilate the UEFI specification and use\r
- the ready to boot event class defined in UEFI 2.0. This library supports\r
- the EDK/EFI 1.10 form and EDK II/UEFI 2.0 form and allows common code to\r
- work both ways.\r
-\r
- @param ReadyToBootEvent Returns the EFI event returned from gBS->CreateEvent(Ex).\r
+ @param ReadyToBootEvent Returns the EFI event returned from gBS->CreateEvent(Ex).\r
\r
@retval EFI_SUCCESS Event was created.\r
@retval Other Event was not created.\r
\r
\r
/**\r
- Signal a Ready to Boot Event.\r
-\r
- Create a Ready to Boot Event. Signal it and close it. This causes other\r
- events of the same event group to be signaled in other modules.\r
+ Create, Signal, and Close the Ready to Boot event using EfiSignalEventReadyToBoot().\r
+ \r
+ This function abstracts the signaling of the Ready to Boot Event. The Framework moved\r
+ from a proprietary to UEFI 2.0 based mechanism. This library abstracts the caller\r
+ from how this event is created to prevent to code form having to change with the\r
+ version of the specification supported.\r
\r
**/\r
VOID\r
}\r
\r
/**\r
- Signal a Legacy Boot Event.\r
+ Create, Signal, and Close the Ready to Boot event using EfiSignalEventLegacyBoot().\r
\r
- Create a legacy Boot Event. Signal it and close it. This causes other\r
- events of the same event group to be signaled in other modules.\r
+ This function abstracts the signaling of the Legacy Boot Event. The Framework moved from\r
+ a proprietary to UEFI 2.0 based mechanism. This library abstracts the caller from how\r
+ this event is created to prevent to code form having to change with the version of the\r
+ specification supported.\r
\r
**/\r
VOID\r
\r
\r
/**\r
- Check to see if the Firmware Volume (FV) Media Device Path is valid\r
-\r
- Tiano extended the EFI 1.10 device path nodes. Tiano does not own this enum\r
- so as we move to UEFI 2.0 support we must use a mechanism that conforms with\r
- the UEFI 2.0 specification to define the FV device path. An UEFI GUIDed\r
- device path is defined for Tiano extensions of device path. If the code\r
- is compiled to conform with the UEFI 2.0 specification use the new device path\r
- else use the old form for backwards compatability. The return value to this\r
- function points to a location in FvDevicePathNode and it does not allocate\r
- new memory for the GUID pointer that is returned.\r
- If FvDevicePathNode is NULL, then ASSERT().\r
+ Check to see if the Firmware Volume (FV) Media Device Path is valid \r
\r
- @param FvFileDevicePathNode Pointer to FV device path to check.\r
+ The Framework FwVol Device Path changed to conform to the UEFI 2.0 specification. \r
+ This library function abstracts validating a device path node.\r
+ Check the MEDIA_FW_VOL_FILEPATH_DEVICE_PATH data structure to see if it's valid. \r
+ If it is valid, then return the GUID file name from the device path node. Otherwise, \r
+ return NULL. This device path changed in the DXE CIS version 0.92 in a non back ward \r
+ compatible way to not conflict with the UEFI 2.0 specification. This function abstracts \r
+ the differences from the caller.\r
+ If FvDevicePathNode is NULL, then ASSERT().\r
+\r
+ @param FvDevicePathNode Pointer to FV device path to check.\r
\r
@retval NULL FvDevicePathNode is not valid.\r
@retval Other FvDevicePathNode is valid and pointer to NameGuid was returned.\r
\r
/**\r
Initialize a Firmware Volume (FV) Media Device Path node.\r
-\r
- Tiano extended the EFI 1.10 device path nodes. Tiano does not own this enum\r
- so as we move to UEFI 2.0 support we must use a mechanism that conforms with\r
- the UEFI 2.0 specification to define the FV device path. An UEFI GUIDed\r
- device path is defined for Tiano extensions of device path. If the code\r
- is compiled to conform with the UEFI 2.0 specification use the new device path\r
- else use the old form for backwards compatability.\r
+ \r
+ The Framework FwVol Device Path changed to conform to the UEFI 2.0 specification. \r
+ This library function abstracts initializing a device path node. \r
+ Initialize the MEDIA_FW_VOL_FILEPATH_DEVICE_PATH data structure. This device \r
+ path changed in the DXE CIS version 0.92 in a non back ward compatible way to \r
+ not conflict with the UEFI 2.0 specification. This function abstracts the \r
+ differences from the caller.\r
If FvDevicePathNode is NULL, then ASSERT().\r
If NameGuid is NULL, then ASSERT().\r
-\r
- @param FvFileDevicePathNode Pointer to a FV device path node to initialize\r
+ \r
+ @param FvDevicePathNode Pointer to a FV device path node to initialize\r
@param NameGuid FV file name to use in FvDevicePathNode\r
\r
**/\r
projects / mirror_edk2.git / blobdiff