3.1 Basic programming model
Common questions about UEFI include:
- How are programs in UEFI implemented?
- What makes UEFI programming different from an operating system?
- What makes UEFI different from other firmware environments?
- In particular, what is the programming model for a UEFI Driver?
Key points about writing UEFI-conformant drivers are that:
- UEFI Drivers are relocatable PE/COFF images whose format is defined by the Microsoft Portable Executable and Common Object File Format Specification.
- UEFI Drivers may be compiled for any of the CPU architectures supported by the UEFI Specification.
- UEFI Drivers run on a single CPU thread.
- The driver support infrastructure does not extend beyond the boot processor.
- Drivers sit above some interfaces (for example, bus abstractions) and below other interfaces: They are both consumers and producers. The UEFI Specification defines the interfaces and they are extensible.
- Each driver is expected to cooperate with other drivers, other modules and the underlying core services.
- The communicating modules bind together to create stacks of cooperating drivers to accomplish tasks.
- Inter-module communication is enabled via interfaces known as protocols and via events.
- Tables provided at invocation provide access to core services.
- The operating environment is non-preemptive and polled. There are no tasks per se. Instead, modules execute sequentially.
- There is only one interrupt: the timer. This means that data structures accessed by both in-line code and timer-driven code must take care to synchronize access to critical paths. This is accomplished via privilege levels.
Last modified 2yr ago