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.