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

DriverWorks предоставляет дополнительные классы для нужд программиста. Это классы очередей, списков, стеков; классы файлов и Unicode–строк; классы синхронизации.

Списки представлены класами KList, KInterlockedList, KInterruptSafeList. Они представляют шаблоны двунаправленных списков и стандартные методы для вставки, удаления и добавления элементов. Различаются эти классы методами синхронизации. KList не содержит никаких методов синхронизации и защиты данных. KInterLockedList использует защелки (spin locks) для защиты внутренних связей в списке. KInterruptSafeList использует присоединенный объект прерывания для защиты связей. По аналогичному принципу работают шаблоны классов FIFO (стек): KFifo, KLockableFifo, KInterruptSafeFifo. Класс KFile инкапсулирует методы для работы с файлами. Этот класс позволяет читать и записывать данные в файл а также изменять атрибуты файлов. Для представления Unicode – строк используется класс KUstring. Методы данного класса позволяют выполнять сравнение, конкатенацию, доступ к символам строки и разнообразные преобразования типа.

Также остается неясным еще один вопрос, связанный с драйверами: как именно с нашим объектом устройства может связаться приложение или другой драйвер? Большинство из устройств в системе именованы, хотя теоретически допускается существование неименованных (anonymous) устройств. Связь с устройством можно установить двумя методами:

• при помощи GUID.

• при помощи символической ссылки.

1. GUID (Globally Unique Identifier, глобально уникальный идентификатор) — 16-байтное уникальное число. GUID используются для идентификации в системе драйверов, СОМ-объектов и т.п. В идеале, во всем мире не может быть двух одинаковых GUID, поэтому GUID может быть абсолютно уникальным идентификатором драйвера. GUID генерируется на основе текущей даты, времени и номера сетевого адаптера, если такой присутствует, и обычно указывается в заголовочном файле класса устройства и программы, которая хочет связаться с ним приблизительно таким образом:

#define MyDevice_CLASS_GUID \

{ 0xff779f4c, 0x8b57, 0x4a65, { 0x85, 0xc4, 0xc8, 0xad, 0x7a, 0x56, 0x64, 0xa6 } }

2. Символическая ссылка (symbloic link) похожа на путь к файлу и в тексте программы имеет вид:

char *sLinkName = "\\\\.\\MyDevice";

Если отбросить лишние символы бэкслэша, необходимые для соблюдения синтаксиса С++, то символическая ссылка оказывается строкой \\.\MyDevice. Чтобы понять принцип работы символической ссылки, следует знать, что в ОС есть системный каталог различных объектов, которые присутствуют в системе: драйверов, устройств, объектов событий, семафоров и т.п. Символическая ссылка – специфический тип объекта, который обеспечивает доступ к другим системным объектам. Специальный подкаталог системного каталога зарезервирован для символических ссылок на другие объекты ОС. Программа пользователя может обратиться к этим символическим ссылкам при помощи функций API.

Как же следует проектировать интерфейс с драйвером? Следует использовать GUID или символическую ссылку?

Идентификация драйвера при помощи GUID считается более правильной. Как было упомянуто выше, специальные алгоритмы гарантируют то, что GUID будет действительно уникальным. А кто мешает разработчику, находящемуся на другом конце света, также создать устройство с той же ссылкой на него \\.\MyDevice? Вообще-то, никто. Но с другой стороны, с написанной на понятном английском языке ссылкой гораздо проще обращаться, особенно на этапе разработки драйвера, чем с длинным и непонятным GUID. Так что, вероятно, на этапе разработки и отладки драйвера для интерфейса драйвера с приложением лучше использовать символическую ссылку, а для коммерческой версии драйвера — GUID.

Процесс разработки драйвера при помощи DriverStudio во многом напоsминает разработку приложения в среде Visual C++. Создание проекта происходит при помощи мастера DriverWizard, похожего на мастер Visual C++. Мастер вызывается или из главного меню (Пуск→Программы→DriverStudio→DriverWorks→DriverWizard) или из среды Visual C++ при помощи пункта меню DriverStudio — DriverWizard. Программе DriverWizard соответствует иконка

Далее при работе мастера появляется серия диалоговых окон, куда пользователь должен ввести данные, необходимые для формирования скелета драйвера.

Рис 6. Первый шаг DriverWizard

На первом шаге создания драйвера необходимо ввести имя проекта (в нашем случае — XDSP и директорию для проекта. После этого — нажать на кнопку Next, чтобы перейти к следующему шагу.

Рис 7. Второй шаг DriverWizard

На втором шаге следует выбрать архитектуру, по которой будет разрабатываться драйвер: Windows NT 4.0 (которая сейчас практически не используется) или WDM, которую нам и следует выбрать.

Рис 8. Третий шаг DriverWizard

На третьем шаге выберем шину, на которой располагается устройство, которое будет контролировать драйвер. Если это устройство будет подключаться к порту компьютера, например к параллельному — надо выбрать None — driver does not control any hardware. Если же устройство будет располагаться на одной из шин компьютера, например на PCI — надо задать дополнительные параметры. В случае PCI устройства надо указать следующие параметры:

• Код производителя (PCI Vendor ID) — четырехзначное шестнадцатеричное число, которое однозначно идентифицирует производителя устройства. Пусть в нашем случае оно будет равно 1999.

• Код устройства (PCI Device ID) — также четырехзначное шестнадцатеричное число, которое однозначно идентифицирует устройство нашего производителя. Пусть в нашем случае это будет 680C.

• Номер подсистемы PCI. Обычно имеет вид код устройства + код производителя. В нашем случае — 680C1999.

• Номер версии устройства (PCI Revision ID) — номер версии устройства. В нашем случае 01.

Эти коды весьма важны: по ним система будет находить драйвер для устройства. Эти же коды аппаратно прошиты в PCI-карточке. И если коды, заданные в драйвере (если быть точным, то они задаются не в самом файле драйвера, а в инсталляционном скрипте — inf-файле), не совпадут с кодами в PCI-устройстве, то драйвер не установится.

Рис 9. Четвертый шаг DriverWizard

На четвертом шаге мастера необходимо задать имена, которые DriverWizard присвоит файлу С++, который содержит класс драйвера, и самому классу драйвера (Driver Class).

Рис 13. Пятый шаг DriverWizard

На пятом шаге следует указать, какие функции должен выполнять драйвер. Это может быть:

• чтение (read) — обработка запросов на чтение.

• запись (write) — обработка запросов на запись.

• сброс (flush) — обычно это сброс буфера обмена с устройством.

• управление устройством (device control) — обработка других запросов.

• внутреннее управление устройством (internal device control) — обработка запросов от других драйверов устройств.