ExitBootServices(), then the OS Loader or OS Kernel must make a copy of the data structure prior calling
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()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_SUCCESSis a key is pressed and
EFI_TIMEOUTif no key is pressed.