- •Введение 5
- •1 Исследовательский раздел
- •1.1 Анализ существующих аналогичных систем
- •1.1.1 Обзор архитектуры устройств usb
- •1.2 Обоснование выбора программно-аппаратных средств
- •1.3 Постановка задачи
- •1.4 Развернутое техническое задание
- •1.4.1 Общие сведения
- •2.1.1 Основные дескрипторы usb драйвера
- •2.1.1.1 Дескриптор устройства
- •2.1.1.2 Дескриптор расширения устройства
- •2.1.1.3 Дескриптор конфигурации
- •2.1.1.4 Дескриптор интерфейса
- •2.1.1.5 Дескриптор конечной точки
- •2.2 Разработка функциональной схемы драйвера
- •2.2.1 Драйвер в иерархии wdm
- •2.2.2 Уровни обмена данными usb устройств
- •2.2.3 Архитектура системного драйвера usb
- •2.2.4 Основные рабочие процедуры драйвера
- •2.2.5 Управление перемещаемостью кода в драйвере
- •2.3 Разработка алгоритмического обеспечения
- •2.3.1 Инициализация драйвера
- •2.3.3 Обработка расширенных запросов ioctl
- •2.3.4 Поддержка запросов Plug and Play
- •2.3.5 Управление питанием
- •2.3.5.1 Обработка запросов irp_mj_power
- •2.3.6 Процедура деинициализации драйвера
- •2.4 Разработка программного обеспечения
- •2.4.1 Процедура DriverEntry
- •2.4.2 Процедура DriverUnload
- •2.4.3 Процедура AddDevice
- •2.4.4 Процедура передачи запроса usbd
- •2.4.5 Обработчики usbCreate и usbClose
- •2.4.6 Обработчик ConfigureDevice
- •2.4.7 Обработчики запросов на чтение и запись
- •3 Технологический раздел
- •3.1 Технология разработки драйверов для операционных систем семейства Windows
- •3.1.1 Архитектура Windows Driver Model
- •3.1.2 Выбор типа разрабатываемого драйвера
- •3.1.3 Разработка usb драйвера
- •3.2 Технология отладки драйверов в операционных системах семейства Windows
- •3.2.1 Основные отладочные тесты
- •3.2.2 Основные «проблемы», возникающие при отладке драйвера
- •3.2.2.1 Аппаратные проблемы
- •3.2.2.2 Программные проблемы
- •3.2.3 Основные отладчики и утилиты для проверки драйвера
- •3.2.3.1 Отладчик WinDbg
- •3.2.3.2 Driver Verifier
- •3.2.4 Общие приемы отладки драйвера
- •3.2.4.1 Установка фиксированных точек прерывания
- •3.2.4.2 Промежуточный вывод на экран
- •3.2.4.3 Сохранение отладочного кода в исходном тексте драйвера
- •3.2.4.4 Перехват некорректных условий
- •3.2.4.5 Обнаружение утечек памяти
- •3.2.5 Замечания по отладке драйверов
- •4 Безопасность жизнедеятельности
- •4.1 Анализ эргономических параметров рабочего места пользователя пэвм
- •4.1.1 Общие эргономические аспекты рабочего места
- •4.2 Организация рабочего места пользователя с учётом эргономических требований
- •4.2.1 Организация рабочего стола
- •4.2.2 Рабочее кресло
- •4.2.3 Работа с клавиатурой и мышью
- •4.2.4 Расположение и эргономические характеристики монитора
- •4.2.5 Внутренний объем
- •4.2.6 Рабочая поза пользователя пэвм
- •4.3 Экологическая оценка и переработка узлов компьютерной техники содержащих платину
- •4.3.1 Извлечение платины из отработанных катализаторов
- •4.3.2 Извлечение платины из радиооборудования и сплавов для электрических контактов
- •5 Экономический раздел
- •5.1 Планирование разработки драйвера с построением графика выполнения работ
- •5.1.1 Определение этапов и работ по созданию программного продукта
- •5.1.2 Расчет трудоемкости и продолжительности работ
- •5.1.3 Построение графика выполнения работ
- •5.2 Расчет затрат на разработку
- •5.3 Оценка экономической эффективности проекта
- •1 К исследовательскому разделу
- •2 К специальному разделу
- •3 К технологическому разделу
- •4 К разделу «Безопасность Жизнедеятельности»
- •5 К экономическому разделу
- •Приложение а Установка драйвера с помощью inf-файла
- •Приложение б Графические материалы
3 Технологический раздел
3.1 Технология разработки драйверов для операционных систем семейства Windows
3.1.1 Архитектура Windows Driver Model
Ни для кого не секрет, что тема драйверов достаточно объемная и сложная, поэтому мы не будем уходить в «дебри» системного низкоуровнего программирования, а рассмотрим лишь в общих чертах особенности драйверных моделей. А для большей наглядности, рассмотрим архитектуру WDM на небольшом примере.
Допустим, программе пользовательского режима потребовалось прочитать данные с устройства. Она вызывает функцию API ReadFile, к примеру. Модуль подсистемы - такой как KERNEL32.DLL - реализует вызов, передавая его к низкоуровневой функции API NtReadFile [3.1]. Низкоуровневый API – довольно важная составляющая WDM да и архитектуры Windows в целом, но о нем чуть позже.
Такие функции, как, например, NtReadFile, является частью системного компонента, называемого менеджером ввода/вывода (I/O Manager). Следует иметь ввиду, что в самой системе не существует конкретного исполняемого модуля с таким именем. Тем не менее, нам потребуется какое-то название для обозначения «облака» функций операционной системы, окружающего драйвер.
В рассматриваемом примере с ReadFile функция NtReadFile создает IRP с основным кодом функции IRP_MJ_READ. Дальнейшее может различаться в деталях, но чаще всего такие функции, как NtReadFile, возвращают управление вызывающей стороне пользовательского режима [3.1].
А теперь немного поводу низкоуровнего API. Низкоуровневый API представляет интерфейс, который позволяет «клиентским» приложениям обращаться к программам (в данном контексте - драйверам) режима ядра. Дело в том, что каждая точка входа данного API является тонкой оберткой для функции режима ядра. Все они проверяют свои параметры, предотвращая возможные дефекты безопасности. Сам вызов использует платформенно-зависимый интерфейс для передачи управления через границу пользовательского режима/режима ядра (например, инструкции ассемблера и т.п.). Функции низкоуровнего API работают в режиме ядра и обслуживают запросы приложений на обращение к устройству. Как правило, они создают структуру данных, называемую пакетом запроса ввода-вывода, или IRP (I/O Request Packet), и передают ее в точке входа некоторому драйверу устройства.
Для выполнения запроса IRP драйверу, в конечном счете, потребуется обратиться к своему устройству. Драйверы, хотя они и работают в режиме ядра и могут напрямую общаться с оборудованием, используют средства прослойки HAL (Hardware Abstraction Layer) для обращения к оборудованию. Функции HAL используют платформенно-зависимую реализацию для выполнения операций. Закончив операцию ввода/вывода, драйвер завершает обработку IRP, вызывая соответствующую функцию режима ядра. Завершение является последним этапом обработки IRP и позволяет ожидающему приложению продолжить работу. Для большей наглядности рекомендую обратиться к рисунку 3.1.
Рисунок 3.1 – Схема работы драйверов WDM
Вот, собственно, по такому принципу и работают драйверы WDM. Конечно, то, что мы рассмотрели, это, примерно, сотая часть архитектуры WDM и всего того, что с ней связано. Однако, в рамках данного раздела, надеюсь, вполне достаточно.
Итак, вот несколько ключевых особенностей драйверной модели WDM [3.2]:
Совместимость на уровне двоичных кодов между драйверами для Windows 98 и NТ;
Поддержка управления питанием (power management), что дает системе возможность осуществления энергосбережения путем выборочного отключения питания нескольких или всех устройств в системе;
Поддержка Plug and Play;
Поддержка "продвинутого" шинного управления (advanced bus management);
Единая обработка операций ввода/вывода посредством общей структуры данных - IRP (в Windows 98/Ме существовали серьезные различия в работе с дисками, коммуникационными портами, клавиатурами и т. д.).