Device Path

From PhoenixWiki

Jump to: navigation, search

See Also: Device Path Reference

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 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.

A Device Path is a variable-length binary structure that is made up of variable-length generic Device Path Nodes. The Device Path Node is prefixed by the EFI_DEVICE_PATH_PROTOCOL. See EFI_DEVICE_PATH_PROTOCOL for a description of the different types of Device Path Nodes.

A Device Path is a series of generic Device Path Nodes. The first Device Path Node starts at byte offset zero of the Device Path. The next Device Path Node starts at the end of the previous Device Path node. Therefore all nodes are byte-packed data structures that may appear on any byte boundary. All code references to device path notes must assume all fields are unaligned. Since every Device Path Node contains a length field in a known place, it is possible to traverse Device Path Nodes that are of an unknown type. There is no limit to the number, type, or sequence of nodes in a Device Path.

A Device Path is terminated by an End of Hardware Device Path node. This type of node has two sub-types:

  • End This Instance of a Device Path (sub-type 0x01). This type of node terminates one Device Path Instance and denotes the start of another. This is only required when an environment variable represents multiple devices. An example of this would be the ConOut environment variable that consists of both a VGA console and serial output console. This variable would describe a console output stream that is sent to both VGA and serial concurrently and thus has a Device Path structure that contains two complete Device Paths.
Multi-Instance Device Path
  • End Entire Device Path (sub-type 0xFF). This type of node terminates an entire Device Path. Software searches for this sub-type to find the end of a Device Path. All Device Paths must end with this sub-type.
Simple Device Path

The EFI_DEVICE_PATH_UTILITIES_PROTOCOL provides various useful functions for manipulating Device Paths and Device Path Nodes. The EFI_DEVICE_PATH_TO_TEXT_PROTOCOL and EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL convert a binary device path to and from its standard text encoding.


Copyright (C) 2008,2010 Phoenix Technologies Ltd. All Rights Reserved. Portions copyright (C) 2008 UEFI Forum, Inc. Used with permission

Personal tools