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

Все вышесказанное, конечно, может быть очень интересным, но остается открытым вопрос: так как же все-таки драйвер, вернее объект устройства, управляет аппаратурой? Официально провозглашается, что 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.

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