3.10.1 Device driver
The Start() service of a device driver installs protocol(s) directly onto the controller handle that was passed into the Start() service. The protocol(s) installed by the device driver use the I/O services that are provided by the bus I/O protocol that is installed on the controller handle. For example, a device driver for a USB device uses the service of the USB I/O Protocol, and a device driver for a PCI controller uses the services of the PCI I/O Protocol. In other words, the PCI I/O Protocol is consumed by a driver for a PCI option ROM card. This process is called "consuming the bus I/O abstraction."
The following are the main objectives of the device driver:
  • Initialize the controller.
  • Install an I/O protocol on the device that can be used directly or indirectly by UEFI-conformant system firmware to boot an operating system.
It does not make sense to write device drivers for devices that cannot be used to boot a platform. The following table provides the list of standard I/O protocols that the UEFI Specification defines for different classes of devices. If multiple protocols are listed, that does not necessarily mean that all the protocols must be produced. Please see later sections of the guide and the UEFI Specification for details on which protocols are required and which are optional.

Table 11-I/O protocols produced in the Start() function for different device classes

Class of device
Protocol(s) created in the Start section of the driver
Block Oriented Device
File System
Non block oriented or file system based boot device
Universal Network Driver Interface (UNDI)
Graphics Display
Text Console
Character based I/O device
The fundamental definition of a UEFI device driver is that it does not create any child handles. This difference distinguishes a device driver from a bus driver.
The definition of a device driver can be confusing because it is often necessary to write a driver that creates child handles. This necessity makes the driver a bus driver by definition, even though the driver may not be managing a hardware bus in the classical sense (such as a PCI, SCSI, USB, or Fibre Channel bus).
Even though a device driver does not create child handles, the device managed by the device driver could still become a "parent." The protocol(s) produced by a device driver on a controller handle may be consumed by a bus driver that produces child handles. In this case, the controller handle that is managed by a device driver is a parent controller. This scenario happens quite often.
For example, the EFI_USB2_HC_PROTOCOL is produced by a device driver called the USB host controller driver. The protocol is consumed by the USB bus driver. The USB bus driver creates child handles that contain the USB_IO_PROTOCOL. The USB host controller driver that produced the EFI_USB2_HC_PROTOCOL has no knowledge of the child handles that are produced by the USB bus driver.
Copy link