Filter
Top Products
Services — Boot Services
Version 1.10 12/01/02 5-33
The ability to add new protocol interfaces as new handles or to layer them on existing interfaces
provides great flexibility. Layering makes it possible to add a new protocol that builds on a
device’s basic protocols. An example of this might be to layer on a SIMPLE_TEXT_OUTPUT
protocol support that would build on the handle’s underlying SERIAL_IO protocol.
The ability to add new handles can be used to generate new devices as they are found, or even to
generate abstract devices. An example of this might be to add a multiplexing device that replaces
ConsoleOut with a virtual device that multiplexes the SIMPLE_TEXT_OUTPUT protocol onto
multiple underlying device handles.
5.3.1 Driver Model Boot Services
This section provides a detailed description of the new EFI boot services that are required by the
EFI Driver Model. These boot services are being added to reduce the size and complexity of the
bus drivers and device drivers. This, in turn, will reduce the amount of ROM space required by
drivers that are programmed into ROMs on adapters or into system FLASH, and reduce the
development and testing time required by driver writers.
These new services fall into two categories. The first group is used to track the usage of protocol
interfaces by different agents in the system. Protocol interfaces are stored in a handle database.
The handle database consists of a list of handles, and on each handle there is a list of one or more
protocol interfaces. The boot services InstallProtocolInterface()
,
UninstallProtocolInterface()
,andReinstallProtocolInterface() are used
to add, remove, and replace protocol interfaces in the handle database. The boot service
HandleProtocol()
is used to look up a protocol interface in the handle database. However,
agents that call HandleProtocol() are not tracked, so it is not safe to call
UninstallProtocolInterface() or ReinstallProtocolInterface() because an
agent may be using the protocol interface that is being removed or replaced.
The solution is to track the usage of protocol interfaces in the handle database itself. To accomplish
this, each protocol interface includes a list of agents that are consuming the protocol interface.
Figure 5-2 shows an example handle database with these new agent lists. An agent consists of an
image handle, a controller handle, and some attributes. The image handle identifies the driver or
application that is consuming the protocol interface. The controller handle identifies the controller
that is consuming the protocol interface. Since a driver may manage more than one controller, the
combination of a driver's image handle and a controller's controller handle uniquely identifies the
agent that is consuming the protocol interface. The attributes show how the protocol interface is
being used.