Александр Тарво - Использование NuMega DriverStudio для написания WDM-драйверов Страница 4

Класс KDevice является суперклассом для всех классов устройств. Но на практике он сейчас почти не используется. Чаще используют его потомка – класс KPnpDevice. Этот класс предназначен для управления PnP-устройствами, т.е. устройствами, которые конфигурируется системой. В данный момент практически все устройства являются PnP-устройствами. Появление таких устройств здорово облегчило жизнь разработчикам драйверов: использовать KPnpDevice намного проще, а часто и безопаснее, чем KDevice. Еще бы, ведь в данном случае все проблемы конфигурирования и инициализации ресурсов оборудования ложатся на широкие плечи системы.

Любой объект устройства содержит стандартные методы обработки запросов на чтение, запись и управление устройством (device control). Эти методы вызываются при вызове соответствующих функций API ReadFile(), WriteFile(), DeviceControl().

Каждый драйвер содержит минимум один объект устройства. Как было упомянуто выше, объект устройства является экземпляром класса, порожденного программистом от класса KDevice или KPnpDevice. Для придания функциональности объекту устройства разработчик драйвера может переопределять виртуальные методы суперкласса, включая те методы, которые обрабатывают различные типы IRP, а также добавлять свои свойства и методы в класс. В процессе разработки можно использовать как иерархию классов DriverStudio, так и функции DDK. Впрочем, для большинства задач без использования DDK вполне можно обойтись.

Естественно, делать все это надо с осторожностью. Вызов некотроых методов является обязательным. Переопределение виртуальных методов также требует осторожности: многие из них содержат код, который обязательно должен быть выполнен. Если его удалить, то драйвер будет работать неправильно (если будет работать вообще). В результате, система скорее всего, зависнет.

Все вышесказанное, конечно, может быть очень интересным, но остается открытым вопрос: так как же все-таки драйвер, вернее объект устройства, управляет аппаратурой? Официально провозглашается, что Win2000 — переносимая система. Т.е., если она хорошо работает на архитектуре Intel, то она также может быть перенесена и на другие системы, например Alpha. Для того, чтобы система с минимальными исправлениями могла работать на компьютерах с другой архитектурой, и был введен HAL — уровень абстракции аппаратуры. Он действительно абстрагирует драйвера и большую часть кода ядра ОС от того, как именно построен компьютер. Теперь разработчику драйвера становится абсолютно все равно, как на данном компьютере реализован контроллер прерываний или контроллер прямого доступа к памяти – все ресурсы аппаратуры также представлены объектами. Это диапазоны адресов памяти и портов В/В устройства, линии прерываний и ПДП. Все они могут быть реализованы в различных архитектурах по разному, но общие принципы их работы остаются одними и теми же. Соответственно, и интерфейс классов, реализующих управление этими ресурсами, остается одинаковым. Нам, как программистам, теперь не нужно знать тонкости работы аппаратной части на этом компьютере — это задача HAL и тех людей, которые переносили систему.

На практике это означает то, что если устройство, например, имеет диапазон адресов памяти и линию запроса на прерывание, то класс устройства будет содержать два свойства (данные). Одно из них — экземпляр класса KMemoryRange, который будет реализовывать управление памятью устройства, а другое — экземпляр класса KInterrupt, который управлет линией запроса на прерывание, и всем, что с ней связано. Если устройство будет иметь несколько областей адресов памяти, то, соответственно, класс устройства будет содержать несколько экземпляров класса KMemoryRange.

Другим способом управления устройствами является наличие устройств нижнего уровня (Lower devices). Как уже было отмечено, особенностью архитектуры WDM является наличие стека драйверов, когда драйвера могут обмениваться IRP-пакетами между собой. Данную ситуацию легче объяснить при помощи рисунка:

Рис. 4 — стек устройств

На рис. 4 изображен стек устройств, состоящий из трех объектов устройств. Устройство 1 — самое первое (верхнее) в стеке, устройство 3 — самое последнее (нижнее) в стеке. Тогда по отношению к устройству 1 устройство 2 будет устройством нижнего уровня. Устройства верхнего уровня для устройства 1 нет. Устройство 2 имеет и устройство верхнего уровня (устройство 1) и устройство нижнего уровня (устройство 3). Для устройства 3 есть только устройство верхнего уровня (устройство 2), устройства нижнего уровня у него нет, устройство 3 напрямую контролирует оборудование.

Такой метод управления оборудованием, когда в системе присутствует не один драйвер, а целая цепочка драйверов, может иметь свои преимущества. Предположим, наше физическое устройство — это клавиатура, подключенная к USB–порту. Тогда объект устройства 3 — драйвер USB–порта. Устройство 2 выполняет действия, специфичные именно для данного типа клавиатур: читает данные из портов ввода-вывода клавиатуры, "висит" на прерывании, выполняет дополнительные функции (например, если у нас мультимедийная клавиатура). Он передает коды нажатых клавиш устройству 1. Устройство 1 не зависит от того, какой именно тип клавиатуры подключен к компьютеру. Оно реализует очередь кодов нажатых клавиш; реакцию на клавиши CapsLock, Shift и т.п.

Если в данном случае у компьютера поменяется клавиатура, то необходимо установить только новый драйвер 2. Если клавиатура переключится на другой порт, то устройство 2 будет общаться не с устройством 3, а с каким-то другим устройством. В таком случае система становится более гибкой, легкой в проектировании, более надежной и простой в использовании. И пользователю, и приложениям становится абсолютно все равно, какой тип клавиатуры установлен на компьютере.

В нашем примере получается, что и устройство 1, и устройство 2 управляет оборудованием – клавиатурой. Но они делают это не напрямую, а посылая IRP устройству 3. Для того, чтобы наш объект устройства мог передавать IRP–пакеты другим объектам устройств, введен класс устройств нижнего уровня (KLowerDevice, KPnpLowerDevice). Естественно, для этого устройство должно знать, как управлять устройством нижнего уровня при помощи IRP.

Впрочем, подбная ситуация имеет место практически во всех современных ОС. Только в других системах это выражено менее ярко и не декларируется, как "официальная идеология".

Затрагивая тему управления аппаратурой, нельзя не упомянуть еще об одном способе управления устройствами. Иногда нет возможности использовать классы DriverWorks или функции DDK. Например, необходимо обратится непосредственно к портам ввода-вывода компьютера, в частности, к портам управления принтером. Напрямую сделать это из приложения пользователя, работающего под Win2000, невозможно. Все пользовательские программы работают в непривилегированном кольце защиты 3 и не могут выполнять ассемблерные команды типа inp / outp. Но драйвер работает в кольце защиты 0 и, фактически, может делать все что угодно. В этом случае следует переопределить методы класса устройства, например ReadFile(), WriteFile(), DeviceControl() – добавить туда ассемблерные вставки или код на С, выполняющий то, что нам необходимо сделать (чаще всего это обращение к портам ввода-вывода). Впрочем, любое обращение к портам ввода-вывода компьютера напрямую может оказаться опасным. Если программист допустит ошибку или неточность в манипуляциях с параллельным портом, то это, скорее всего, пройдет бесследно для системы. Но если он ошибется при обращении к портам управления таймером, винчестером или другими жизненно важными устройствами компьютера, то в лучшем случае система зависнет.

Сколько операций может параллельно выполнять наше физическое устройство? Естественно, это определяется самой природой этого устройства. Многие виды оборудования могут одновременно делать что-то одно. Например, параллельный порт не может передать два байта за один раз при всем нашем желании, ведь физически это один канал передачи. Но ведь IRP–пакеты могут приходить в любое время! Поэтому большинство объектов устройств должны содержать какой-либо механизм для буферизации и упорядочивания (serialization) запросов, т.к. зачастую только один запрос может быть обработан в единицу времени. Самым простым и в то же время эффективным методом такой буферизации является очередь.

Объекты, внедренные в объект устройства, представлены в классе KDeviceQueue. Его методы не только реализуют манипуляцию с очередью, но и решают более интеллектуальные задачи. Например, есть метод, смысл которого может быть описан таким образом: "Если устройство сейчас обрабатывает запрос и занято, то помести новый запрос в очередь, иначе немедленно начни его обработку". Подобные методы сильно облегчают задачу буферизации запросов для объекта устройства. Но возможна и другая ситуация: устройство может одновременно обрабатывать запросы разного вида. К примеру, наше устройство – это дуплексный канал связи. Оно одновременно может и принимать, и передавать информацию. Если мы будем использовать для буферизации всех одну очередь, то такой подход является неэффективным. Поэтому система позволяет объектам устройств создавать дополнительные объекты очередей. Они реализованы в классе KDriverManagedQueue.