Upload
gregory-underwood
View
245
Download
0
Tags:
Embed Size (px)
Citation preview
Windows Driver Foundation: Introduction
Murtuza NaguthanawalaProgram ManagerNetworking And DevicesMurtuzan @ microsoft.comMicrosoft Corporation
Session GoalsSession Goals
Attendees should leave this session with the following:
A better understanding of Windows Driver Foundation (WDF)
Know how to use WDF
Session OutlineSession Outline
Overview
Limitations of the current driver models
Windows Driver FoundationModel
Kernel mode framework
User mode framework
Static verification tools
Windows Driver Model (WDM): OverviewWindows Driver Model (WDM): Overview
Generic Model – WDM
Specific driver models – Miniports for popular device classes
WDM FeaturesAsynchronous and packet-based IO
Layering of drivers
Dynamic loading and unloading of drivers
Plug and Play
Power management
Large device coverage
Flexible
Low-level high-performance interfaces
Current Windows Driver ModelsCurrent Windows Driver Models
Device/Driver Classes Current ModelDisplay Adapters Video port
Storage Adapters (SCSI & ATA) Scsiport, Storport, ATAport,
Network Adapters NDIS
Video Capture AvStream
Audio Adapters AVStream, PortCls
File System filters FS Mini filter
Printers UniDrv
Scanners,Cameras WIA
PCI, PC Card, generic filter drivers WDM
Modems, Cable Modem WDM & NDIS WDM
Biometric Devices WDM
Smart Card Devices WDM
Keyboard/Mouse Filters WDM
Legacy Devices (Serial, Parallel) WDM
Portable Media Players WMDM
UPnP & Network Connected Devices, Cell Phones
No support
USB, 1394, Bluetooth, SD devices WDM (kernel), no support (user)
Others WDM
Limitations With Current Driver ModelsLimitations With Current Driver Models
Generic driver model is too complex
Poor DDI design
Inconsistent miniport models
The current approach requires many drivers to use kernel mode
User Mode could be an option
Does not allow extension and future growth
Limitations: Generic Driver ModelLimitations: Generic Driver Model
Lots of hard-to-understand boiler plate code
Plug and Play and Power Management (PnP/PM) have complicated state machines
Never coherently described and cannot be well expressed in documentation
Not easily testable
Asynchronous I/O & Cancellation
Synchronization
Documentation is not adequate
End user experienceDrivers are the #1 cause of blue screens in the system
Limitations: DDI DesignLimitations: DDI Design
DDIs directly exposed by kernelKey OS data structures exposed to drivers
Hard to versionEven the OS Version Query DDI is OSversion dependent!
Subtle changes in kernel break driverse.g., Changing the default pool size
Cannot make improvements to the kernel easily
Only C is supported
Limitations: Inconsistent Driver ModelsLimitations: Inconsistent Driver Models
Inconsistent interfaces
Hard to transfer expertise from one device class to another
Not flexible enough to keep up with HW innovation
Device classes appear on multiple buses
Duplication of testing and documentation efforts
Tools/technologies cannot be leveraged across all models
e.g., Driver Verifier, PREfast
Limitations: Kernel mode requiredLimitations: Kernel mode required
Not every device needs interrupts, DMA, register access, has strict timing requirements etc.
Many USB device drivers could be written in user mode
Lower reliabilityKernel-mode drivers can crash the system
Driver Model Design GoalsDriver Model Design Goals
Consistent set of DDIs
DDIs not tied to core OS components
Language agnostic
Supports verification by static analysis tools
Diagnosability
Supports driver isolation Bugs in a driver do not bring down system or other driversDDIs classified into two categories
Base model: Supports base functionality across all device classes, including
PnP, PM, Async I/O, Queues, DMA, hardware access
Synchronization, Communication with drivers
Device class extension Derives from base model; only adds device specific functionality
e.g., Device I/O Control processing
Driver Model for Device Class SupportDriver Model for Device Class Support
Base ModelBase Model(PnP/PM/IO/Synch)(PnP/PM/IO/Synch)
Device Specific Device Specific Extension (Packet, Extension (Packet, Device I/O Control, Device I/O Control,
CDB processing)CDB processing)
DriverDriver
How To Get to Driver Model?How To Get to Driver Model?
Our plan is to get to the driver model goals incrementally
Keep supporting existing driver models WDM will continue to be supported
Existing mini-port models will continue to be supported
Define the basic model
Define a consistent way to extend the basic model
Ensure that newer device classes use the new approach
Windows Driver Foundation
Driver Model and Windows Drivers Driver Model and Windows Drivers FoundationFoundation
WDFWDF(PnP/PM/IO/Synch)(PnP/PM/IO/Synch)
Device Specific Device Specific Extension (Packet, Extension (Packet, Device I/O Control, Device I/O Control,
CDB processing)CDB processing)
DriverDriver
WDF becomes the base model
Windows Driver Foundation- ExperienceWindows Driver Foundation- Experience
Windows Driver FoundationWindows Driver Foundation
WDF is the stepping-stone to the ideal driver model
WDF ContainsA Model
Multiple frameworksKernel Mode Framework
User Mode Framework
Verification ToolsStatic Driver Verifier
PREfast for Drivers
PREfast
KernelMode
Framework
User ModeFramework
Static Driver
Verifier
WDFModel
Windows Driver Foundation - Goals Windows Driver Foundation - Goals
Simplicity: No harder than it needs to be to accomplish a task
Fast time to market for drivers
Reduce crashes and blue screens generated by drivers in the system
Provide complete driver development experienceDriver model
UMDF, KMDF
Develop,test and qualifyBuilt-in diagnosibility, tracing, verification tools
Logo programs for drivers
Deployment, Install and MaintainSupport versioning
Windows Driver Foundation: ModelWindows Driver Foundation: Model
One conceptual model to learn for all (both kernel and user-mode) drivers
Model impliesObject model, object hierarchies, state machines
Does not refer to DDIs, data structures etc.
Note that a framework may only implement a subset of the model
e.g., User mode framework will not implement support for Interrupts
Supports rich and deep functionality (unlike WDM)Intelligent defaulting
Allows implementation in many languages (C, C++)
Allows verification by static tools
Enables driver isolation using user mode driver framework
WDF Value PropositionWDF Value Proposition
A quicker, cheaper and easier way of developing and deploying your driver to market
Reduced chances that device driver is a cause of system crash
Reduced support costsBetter diagnosability and debugging and logging support
Improved system stability and reliability
Higher quality drivers
Automated discovery of driver bugs via static tools
System robustness
Better system security
User mode tools like Visual Studio can be used for development
Better power management
Consistent experience across pluggable devices
Device Class / Driver Model KMDF UMDF SDV PFD
Modem, CD ROM devices, Keyboard, Mouse Yes No Yes Yes
SCSI – StorPort No No No Yes
Display cards No No No Yes
Ethernet devices No No No Yes
DSL/Cable Modems Yes No No Yes
Video Capture devices (Webcams) No No No Yes
Anti-virus filters No No Yes Yes
Digital cameras/portable media players/cell phones/PDAs etc No Yes No Yes
Printers No No No Yes
Scanners No No No Yes
WDF Device Support Scope: LonghornWDF Device Support Scope: Longhorn
Kernel Mode Driver Framework
Kernel Mode Driver FrameworkKernel Mode Driver Framework
Previously referred to as “Windows Driver Framework”
Implements the model in kernel mode
Built as a library on top of WDM
Supported from Windows 2000 and forward
Beta/Pre-release bits are available today
Object based
‘C’ only
SupportsPNP and Power
WMI
DMA
Requests and Queue
IO targets
Kernel Mode Driver Framework StatusKernel Mode Driver Framework Status
Feature completee.g. Object Model, PnP/PM, I/O queues etc.
Beta bits are available through beta program22 samples in the kitInstalls with Windows Server SP1 DDK
Current Windows codenamed “Longhorn” drivers using KMDF
Universal audio bus driverWinUSBMonitor function driverInternal MSFT test drivers
DDIs are open to refinement based on feedback from the WDF beta program
Kernel Mode Driver Framework Proof Points
Case Study: PCIDRV SampleCase Study: PCIDRV Sample
Metric WDM WDF Comments
Line Count 13147 7271 Explicit registration of granular event callbacks add to the line count
LOC devoted to PnP/PM
7991 1795 Almost 6000 lines of code is eliminated
Locks 8 3 This is the most important stat. This explains the complexity
State variables devoted to PnP/PM
30 0 This explains that there are fewer paths in the driver and thus less testing and complexity
This sample is written for the Intel E100B NIC Card. This is a WDM version of a network driver. Both samples are in the DDK and are functionally equivalent.
Case Study: Serial SampleCase Study: Serial Sample
Metric WDM WDF Comments
Line Count 24000 17000 Explicit registration of granular event callbacks add to the line count
LOC devoted to PnP/PM 5000 2500
Locks & Synchronization Primitives 10 0 This is the most important stat. This explains the complexity
State variables devoted to PnP/PM 53 0 There are fewer paths in the driver and hence less complexity
WDF sample does not support multi-port serial (WDM sample supports it).
WDM stats exclude multi-port support serial code
Case Study: OSRUSBFX2 SampleCase Study: OSRUSBFX2 Sample
Metric WDM WDF Comments
Line Count 16350 2300 Explicit registration of granular event callbacks add to the line count
LOC devoted to PnP/PM 6700 742 742 includes code to initialize the USB
Locks (6 Events, 3 SpinLocks) 9 0 This is the most important stat. This explains the complexity
State variables devoted to PnP/PM 21 0 There are fewer paths in the driver and hence less complexity
The WDM version of OSRUSBFx2 sample available on osronline.com and the WDF version provided in the DDK are functionally equivalent.
User Mode Driver Framework
User Mode Driver FrameworkUser Mode Driver Framework
Implements the model in user mode
Support for:PnP/PM, Asynchronous I/O, layering
No support for: Interrupts, DMA, access to hardware registers, client address space etc.
Languages C++
Fits within the Windows I/O modelNaming, security, discovery APIs remain the same
Applications write to Win32 APIs
Supports recovery from driver crashes increase system robustness
Kernel mode drivers CANNOT be stacked on top of user mode drivers
Supported in Longhorn onlyDown level support to Windows XP being evaluated
Kernel Mode/User Mode Feature Kernel Mode/User Mode Feature ComparisonComparison
Feature KMDF UMDF
PnP/PM Yes Yes
Async I/O Yes Yes
Filter support Yes Yes
Recovery from failure No Yes
Languages C C++
Interrupts, DMA etc Yes No
Driver Installation Yes Yes
When KMDFDMA, Interrupt, requires use of non paged pool, strict timing requirements
Access to hardware
When UMDFSoftware drivers, drivers that just need PNP and IO support
Devices on protocol bus (USB-based “Hello Kitty device”)
User Mode Driver Framework StatusUser Mode Driver Framework Status
WinHECDevelopment platform is Windows Driver Kit (WDK)
Current Windows Team ClientsActiveSync (Windows Mobile devices)
MTP (media players, cameras)
Aux display
Potential device classesCellular phones
Portable media players, Scanners, Cameras
Network connected devices
Any protocol bus (USB) based devices not related to input, display, storage or networking
Devices that need PNP and IO support
Verification ToolsVerification Tools
Verify that drivers follow interface specifications
DynamicDriver Verifier already built in to Windows
Static PREfast
Verifies rules within the scope of a function
Many WDM specific rules (IRQL checking) have been added
Static Driver VerifierUses formal checking technology
Examines the entire code path in the driver
Currently focused on verifying WDM rules
WDF interfaces designed to be easily verified by these tools
Works on both Kernel and User mode driver frameworks
SummarySummary
WDF is the new driver model for driver development
It addresses key IHV/OEM concernsFast time to market, technical support costs, learning curve etc
KMDF backward compatible up to Windows 2000
It intends to reduce customer pain points
WDF intends to provides a complete driver development experience
Aims to reduce OS crashes due to poorly-written drivers
WDF targets production of high quality of drivers for Windows
Call to ActionCall to Action
Work together with us to make WDF successfulConsider WDF for any Windows driver development projectJoin WDF beta program
Use the guest account (Guest ID: Guest4WDF) on http://beta.microsoft.com to sign up for beta
Contact infoEmail
Kmdffdbk @ microsoft.com - Kernel Mode Driver FrameworkUmdffdbk @ microsoft.com - User Mode Driver FrameworkPfdfdbk @ microsoft.com - PREfast for DriversSdvfdbk @ microsoft.com - Static Driver Verifier
Newsgroupsmicrosoft.beta.windows.driverfoundationmicrosoft.beta.windows.driverfoundation.announcements
Web Resourceshttp://www.microsoft.com/whdc/driver/wdf/default.mspx
http://www.microsoft.com/whdc/DevTools/ddk/default.mspx
Community ResourcesCommunity Resources
Windows Hardware & Driver Central (WHDC)www.microsoft.com/whdc/default.mspx
Technical Communitieswww.microsoft.com/communities/products/default.mspx
Non-Microsoft Community Siteswww.microsoft.com/communities/related/default.mspx
Microsoft Public Newsgroupswww.microsoft.com/communities/newsgroups
Technical Chats and Webcastswww.microsoft.com/communities/chats/default.mspx
www.microsoft.com/webcasts
Microsoft Blogswww.microsoft.com/communities/blogs
© 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.