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.