Драйверная модель wdf
Казалось бы, у драйверной модели WDM есть все необходимое, чтобы разработчики драйверов могли жить «счастливо», однако у данной модели был и ряд недостатков. А какие именно – мы рассмотрим далее.
И так, мир драйверов Windows изменился 5 декабря 2005 года, когда Microsoft выпустила первую версию Windows Driver Foundation (WDF) Kernel Mode Driver Framework (KMDF) вкупе с User Mode Driver Framework (UMDF) [1]. Новая драйверная модель! Что же в ней примечательного?
Собственно, драйверы WDF используются для тех же целей, что и драйверы WDM: они осуществляют взаимодействие между Windows и устройством. Однако, конструкция операционных систем семейства Windows, поддерживающих драйверы WDM, накладывала на сами драйверы огромную нагрузку по синхронизации событий Plug and Play и управлению энергопотреблением с запросами ввода/вывода. Более того, сама реализации WDM-драйвером функций Plug and Play и энергопотребления довольна сложна в реализации и оставляла желать лучшего. Новая модель WDF как раз и была призвана решить данную проблему, а также некоторые другие насущные проблемы, связанные с разработкой драйверов [3].
Хотя WDF представляет новую драйверные модель, она не является отдельной от WDM. Модель WDF разработана, чтобы заменить модель WDM в качестве главной драйверной модели Windows, предоставляя уровень абстракции над моделью WDM, т.е. при этом механизм WDM продолжает работать в фоне. Таким образом, WDF предоставляет инфраструктуру, которая выполняет ключевые задачи драйверов WDМ: получает и обрабатывает пакеты IRP, управляет изменениями в состоянии Plug and Play и энергопитания, и т.д..
«Изюминкой» WDF является то, что она предлагает набор объектов, которые предоставляют различные, связанные с Windows-драйверами, базовые структурные компоненты, например, запрос ввода/вывода, очередь и т.д. Драйверы WDF используют объекты инфраструктуры для реализации различных аспектов функциональности драйвера. Каждый объект предоставляет программный интерфейс, который драйвер использует для доступа к свойствам объекта или чтобы дать объекту указание выполнить задачу. Каждый объект также поддерживает один или более сообщений, которые вызываются в ответ на такие явления, как изменение системного времени или прибытия запроса ввода/вывода.
Таким образом, задача разработчика заключается в том, чтобы собрать соответствующие объекты в структуру, которая поддерживает соответствующие требования устройства. В зависимости от конкретных требований устройства, структуры отличаются в деталях реализации, но все драйверы WDF создаются из одних и тех же базовых блоков [3].
По умолчанию инфраструктура предоставляет обработку для всех сообщений, поэтому драйверу WDF не обязательно обрабатывать их. В результате этой полной зависимости от инфраструктуры для стандартной обработки сообщений драйвер может получиться «слабо функциональным» и «ограниченным». Чтобы заменить стандартную обработку сообщений инфраструктуры своими обработчиками, драйвер WDF должен явным образом зарегистрировать специальную функцию обратного вызова. Инфраструктура вызовет эту функцию обратного вызова (извиняюсь за некоторую тавтологию), чтобы сообщить драйверу WDF о возникновении сообщения и позволить ему выполнить необходимое обслуживание (рис. 2).
Рисунок 2 – Общая архитектура модели WDF
Именно эта модель сообщений является ключевым аспектом WDF. Драйверы WDF регистрируют функции обратного вызова только для тех сообщений, для которых стандартная обработка, предоставляемой инфраструктурой, не является достаточной. Все остальные сообщения обрабатываются инфраструктурой, без вмешательства драйвера [2].
В состав драйверной модели WDF входит три компонента [2]:
Среда для разработки драйверов режима ядра (Kernel-Mode Driver Framework - KMDF).
Среда для разработки драйверов пользовательского режима (User-Mode Driver Framework - UMDF).
Инструменты для проверки и отладки драйверов.
Второй компонент представляет для нас наибольший интерес – драйверы, выполняющиеся в пользовательском режиме. Перемещение исполнения драйверов в пользовательский режим дает многие преимущества. Например, сбои драйверов пользовательского режима можно полностью изолировать, и работу системы можно восстанавливать без перезагрузки или иных манипуляций. Среда программирования и отладки в пользовательском режиме намного проще, чем в режиме ядра.
Сама инфраструктура UMDF — это программная модель на основе СОМ. Драйвер UMDF – это DLL-ка, состоящая из набора внутрипроцессных объектов обратного вызова на основе COM, которые обрабатывают события, вызванные соответствующими объектами инфраструктур (рис. 3) [3].
Рисунок 3 - Инфраструктура UMDF