User-Mode Driver Framework: Introduction And Overview

1. User-Mode Driver Framework: Introduction And Overview Jeffrey CopelandProgram ManagerWindows Device Experience GroupMicrosoft Corporation

2. Introduction • What this talk covers • Overview • Future directions • Intended audience • Other sessions of interest • Following talk on UMDF architecture • Tomorrow’s UMDF lab session and Q&A

3. Why User Mode? • High-quality drivers are difficult to write • Crash statistics prove this • User mode drivers are “safer” • Some Windows driver models already live in user space • Printers, audio, imaging • UMDF is the general purpose user space model

4. A Quick Word About WDF • Windows Driver Foundation is the successor to WDM • WDM is deprecated • New Kernel Mode and User Mode driver frameworks – KMDF and UMDF • These fit into the driver life cycle • Driver kit • Test tools • Installation tools

5. How To Expose A Device • You can use a stand-alone application with a DLL to directly access the device • Non-shared device • You can write a service to share the device • You can write a driver to use normal I/O • Not WDM – Old technology • UMDF? • KMDF?

6. UMDF versus KMDF • When to use UMDF • Protocol buses – USB, 1394, IP • Software-only drivers – Filters, virtual ports • You must use KMDF if you need • More stringent timing requirements • Hardware access – DMA, interrupts • Kernel-mode clients or access to kernel data • Hybrid-model drivers

7. Where Can You Use UMDF?

8. Where Can You Use UMDF? • Today • Device classes: • Cell phones, media players, cameras, other portable devices • RFID, NFC • Biometric and other security devices • Devices which currently are accessed directly through applications or services • Buses: • USB – through WinUSB I/O Target • IP – sockets through WinSock • Bluetooth – RFCOMM or WinSock • Any bus that provides user-mode access

9. Where Can You Use UMDF? • Factors to consider today • Can the device use a UMDF class driver? • Can the driver access device over that bus? • Does the kernel need to access the device? • Future • Working with device teams to drive availability • Need Feedback to help set priorities

10. UMDF Developers • Existing driver developers • Who want to move drivers to user space • Who already have the “driver mindset” • New driver developers • Coming from application development • Who need to provide device support • Who are learning new skills • Anyone who wants to • Build a driver without a lot of development overhead • Reduce the risks associated with traditional drivers • Stop causing blue screens

11. UMDF Developers • UMDF developers come from two directions • The application programmer still needsto understand something about low-level system facilities Application Programmers KernelProgrammers

12. UMDF Structure • UMDF driver • Framework loads driver • Driver then creates structure andspecifies callbacks and event handlers • C++ and “COM-lite” • For more details stay for the UMDF technical talk

13. Framework Framework UM driver UM driver UMDF Structure Driver Manager Device Stack Host Process CoInstaller User Kernel Reflector Kernel Driver ... Kernel Driver

14. Performance • Test system: hyper-threaded 3.2Ghz P4, 1GB • Performance sample available • Null driver • Raw throughput up to 4 gigabits/sec • Buffer size “sweet spot” 64-128 Kb • Win32 I/O target – USB hard drive • Throughput 170 megabits/sec • CPU usage 11% • UMDF can easily saturate a USB 2.0bus’s maximum speed of 480 megabits/sec • No adverse performance impact in existing UMDF drivers

15. Why To Use UMDF • Single WDF model – Both KM and UM • Quicker development time • PnP/Power boilerplate is encapsulated • Debugging in user mode is easier! • Crashes in testing don’t force a reboot • Access to user-mode services • Shallow learning curve for application developers

16. Why To Use UMDF • Improved stability • UM drivers are isolated from each other • Kernel is isolated from UM drivers • A step toward general driver isolation • Increased security • Compromised driver can’t crash the system • But may still compromise device data • Recoverability • Driver can recover or be restarted aftera crash without a blue screen

17. Why To Use UMDF • “Writing a UMDF driver is relatively easy once you get your hands around using COM-lite.  Perhaps best of all, when your driver crashes while you're debugging it, the system stays running.” – Mark Cariddi, OSR – The NT Insider • “Plug-and-play and power management are easier to use. Queues and I/O targets are straight-forward, and they have what I needed already.” – Janet Schneider, Microsoft Storage Team

18. Why To Use UMDF • “UMDF allows me to focus on the functional implementation, rather than the intricaciesof driver development. The best part about UMDF drivers is that a crash doesn't causea blue screen.”– Dan Polivy, Microsoft SideShow developer

19. Smart Card As A Case Study • Rewrite of an existing WDM driver • Developer had driver knowledge,but not WDM or WDF experience • 2 months to come up to speed onWDF and the existing driver • 1½ months to re-implement thedriver in UMDF

20. Smart Card As A Case Study • 35% code reduction – measured in source bytes • 4000 lines of PnP code removed • Functionally identical driver with less code, higher robustness, more maintainability • Code now “feels simpler” • Results are similar to experience porting WDM network and modem drivers to KMDF

21. Smart Card Janet Schneider Storage Driver developer Microsoft

22. SideShow Dan Polivy Mobile PC developer Microsoft

23. UMDF Availability • Beta UMDF available • For Windows Vista now • For Windows XP next week • As update to the Beta 2 Windows Driver Kit • Available for Windows Server 2003 at same time as release for Windows Server codenamed "Longhorn"

24. UMDF In The Future • New driver models will move to WDF • New features in UMDF • We’re in post-Windows Vista planning now • We need your feedback • Help us decide • Possible convergence on OS platforms • Windows Mobile

25. Resources • Join the WDF Beta Program https://connect.microsoft.com/availableprograms.aspx • Sign in with your Microsoft Passport, and join the WDK/WDF beta • Participate in the UMDF newsgroup microsoft.beta.windows.driverfoundation.umdf atbetanews.microsoft.com • WHDC web site • DevCon 2005 presentations http://www.microsoft.com/whdc/driver/wdf/UMDF.mspx • Join us for the UMDF lab and Q&A Wednesday • Lab requires a Design Preview Agreement • Ask the Experts Tuesday evening

26. Call To Action • Install the Windows Driver Kit • Try UMDF for your driver projects • Send us feedback! • We want to know how to make the framework better • We want to know what features are still missing • Respond to our survey UMDFFDBK @ microsoft.com

27. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.