Intel Extensible Firmware Interface - Manual (Page 67)

Overview
Version 1.10 12/01/02 2-27
2.5.7 Hot-Plug Events
In the past, system firmware has not had to deal with hot-plug events in the preboot environment.
However, with the advent of buses like USB, where the end user can add and remove devices at any
time, it is important to make sure that it is possible to describe these types of buses in the EFI
Driver Model. It is up to the bus driver of a bus that supports the hot adding and removing of
devices to provide support for such events. For these types of buses, some of the platform
management is going to have to move into the bus drivers. For example, when a keyboard is hot
added to a USB bus on a platform, the end user would expect the keyboard to be active. A USB
Bus driver could detect the hot-add event and create a child handle for the keyboard device.
However, because drivers are not connected to controllers unless
ConnectController() is
called, the keyboard would not become an active input device. Making the keyboard driver active
requires the USB Bus driver to call
ConnectController() when a hot-add event occurs. In
addition, the USB Bus Driver would have to call DisconnectController() when a hot-
remove event occurs.
Device drivers are also affected by these hot-plug events. In the case of USB, a device can be
removed without any notice. This means that the
Stop() functions of USB device drivers will
have to deal with shutting down a driver for a device that is no longer present in the system. As a
result, any outstanding I/Orequests will have to be flushed without actually being able to touch the
device hardware.
In general, adding support for hot-plug events greatly increases the complexity of both bus drivers
and device drivers. Adding this support is up to the driver writer, so the extra complexity and size
of the driver will need to be weighed against the need for the feature in the preboot environment.
2.6 Requirements
This document is an architectural specification. As such, care has been taken to specify
architecture in ways that allow maximum flexibility in implementation. However, there are certain
requirements on which elements of this specification must be implemented to ensure that operating
system loaders and other code designed to run with EFI boot services can rely upon a consistent
environment.
For the purposes of describing these requirements, the specification is broken up into required and
optional elements. In general, an optional element is completely defined in the section that matches
the element name. For required elements however, the definition may in a few cases not be entirely
self contained in the section that is named for the particular element. In implementing required
elements, care should be taken to cover all the semantics defined in this specification that relate to
the particular element.