Intel Extensible Firmware Interface, Specification

Page: 135 / 494

Version 1.02 12/12/00 117
5
Device Path Protocol
This chapter contains the definition of the device path protocol and the information needed to
construct and manage device paths in the EFI environment. A device path is constructed and used
by the firmware to convey the location of important devices, such as the boot device and console,
consistent with the software-visible topology of the system.
5.1 Device Path Overview
A Device Path is used to define the programmatic path to a device. The primary purpose of a
Device Path is to allow an application, such as an OS loader, to determine the physical device that
the EFI interfaces are abstracting.
A collection of device paths is usually referred to as a name space. ACPI, for example, is rooted
around a name space that is written in ASL (ACPI Source Language). Given that EFI does not
replace ACPI and defers to ACPI when ever possible, it would seem logical to utilize the ACPI
name space in EFI. However, the ACPI name space was designed for usage at operating system
runtime and does not fit well in platform firmware or OS loaders. Given this, EFI defines its own
name space, called a
Device Path .
A Device Path is designed to make maximum leverage of the ACPI name space. One of the key
structures in the Device Path defines the linkage back to the ACPI name space. The Device Path
also is used to fill in the gaps where ACPI defers to buses with standard enumeration algorithms.
The Device Path is able to relate information about which device is being used on buses with
standard enumeration mechanisms. The Device Path is also used to define the location on a
medium where a file should be, or where it was loaded from. A special case of the Device Path can
also be used to support the optional booting of legacy operating systems from legacy media.
The Device Path was designed so that the OS loader and the operating system could tell which
devices the platform firmware was using as boot devices. This allows the operating system to
maintain a view of the system that is consistent with the platform firmware. An example of this is a
“headless” system that is using a network connection as the boot device and console. In such a
case, the firmware will convey to the operating system the network adapter and network protocol
information being used as the console and boot device in the device path for these devices.