EDK II UEFI Driver Writer's Guide
EDK II UEFI Driver Writer's Guide
EDK II UEFI Driver Writer's Guide
EDK II UEFI Driver Writer's Guide
Introduction
Tables
Figures
Examples
Acknowledgements
1 Introduction
2 UEFI Driver Implementation Checklist
3 Foundation
4 General Driver Design Guidelines
5 UEFI Services
6 UEFI Driver Categories
6.1 Device drivers
6.1.1 Required Device Driver Features
6.1.2 Optional Device Driver Features
6.1.3 Compatibility with Older EFI/UEFI Specifications
6.1.4 Device drivers with one driver binding protocol
6.1.5 Device drivers with multiple driver binding protocols
6.1.6 Device driver protocol management
6.2 Bus drivers
6.3 Hybrid drivers
6.4 Service Drivers
6.5 Root Bridge Drivers
6.6 Initializing Drivers
7 Driver Entry Point
8 Private Context Data Structures
9 Driver Binding Protocol
10 UEFI Service Binding Protocol
11 UEFI Driver and Controller Names
12 UEFI Driver Configuration
13 UEFI Driver Diagnostics
14 Driver Health Protocol
15 Driver Family Override Protocol
16 Driver Supported EFI Version Protocol
17 Bus-Specific Driver Override Protocol
18 PCI Driver Design Guidelines
19 USB Driver Design Guidelines
20 SCSI Driver Design Guidelines
21 ATA Driver Design Guidelines
22 Text Console Driver Design Guidelines
23 Graphics Driver Design Guidelines
24 Mass Storage Driver Design Guidelines
25 Network Driver Design Guidelines
26 User Credential Driver Design Guidelines
27 Load File Driver Design Guidelines
28 IPF Platform Porting Considerations
29 EFI Byte Code Porting Considerations
30 Building UEFI Drivers
31 Testing and Debugging UEFI Drivers
32 Distributing UEFI Drivers
Appendix A EDK II File Templates
Appendix B EDK II Sample Drivers
Appendix C Glossary
Powered by GitBook

6.1.1 Required Device Driver Features

Device drivers are required to implement the following features:

  • A driver entry point that installs one or more instances of the Driver Binding Protocol.

  • Manages one or more controller handles. Even if a driver writer is convinced that the driver manages only a single controller, it is strongly recommended that the driver be designed to manage multiple controllers. The overhead for this functionality is low, and it makes the driver more portable.

  • Does not produce any child handles. This feature is the main distinction between device drivers and bus/hybrid drivers.

  • Ignores the RemainingDevicePath parameter that is passed into the Supported() and Start() services of the Driver Binding Protocol.

  • Consumes one or more I/O-related protocols from the controller handle.

  • Produces one or more I/O-related protocols on the same controller handle.

Previous
6.1 Device drivers
Next
6.1.2 Optional Device Driver Features
Last updated 10 months ago
Edit on GitHub