ExitBootServices()
, then the OS Loader or OS Kernel must make a copy of the data structure prior calling ExitBootServices()
.ExitBootServices()
, so information passed up through protocols must be located by the OS Loader or OS Kernel prior to calling ExitBootServices()
. UEFI Variables are good for small amounts of data, but may consume the scarce variable resources and access to variable storage may be slower than system memory. A configuration table entry is good for larger amounts of data generated each boot and it is stored in system memory. The UEFI Specification defines a set of GUIDs for standard configuration table entries that includes:TPL_APPLICATION
. This means that WaitForEvent()
may not be used from an event notification function because event notification functions always execute at priority levels above TPL_APPLICATION
. If a UEFI Driver needs to know the current state of an event, the CheckEvent()
service should be used instead of WaitForEvent()
. WaitForEvent()
may be used by UEFI Applications. The typical use case is to wait for input from a device such as a keyboard or mouse as part of a user interface. There are a few older protocols that UEFI Drivers may produce that interact with the user and the implementation of these protocols could use WaitForEvent()
. For example, the SetOptions()
function in the Driver Configuration Protocol.WaitForEvent()
is used to wait for one of two events to be signaled. One event is signaled if a key is pressed on the console input device from the UEFI System Table. The other event is a one-shot timer that is signaled after waiting for 1 second. WaitForEvent()
does not return until either a key is pressed or 1 second has passed. This can be used to wait for a key and also update the console with status information once a second. Status is set to EFI_SUCCESS
is a key is pressed and EFI_TIMEOUT
if no key is pressed.