Унифицированная модель драйвера
Требования, которые предъявляются для разработчиков драйверов под NT:
- Драйверы пишутся на языках высокого уровня для обеспечения переносимости.
- Операция В/В управляется IRP-пакетами. IRP используются многократно по слоям. Система динамически назначает драйверы для управления дополнительными новыми.
- Драйверы должны синхронизировать доступ к глобальным данным
- Должны позволять вытеснять потоками более высокого приоритета
- Должны быть прерываемы другими потоками
- Код драйвера должен быть способен выполняться на нескольких процессорах.
- Драйверы должны восстанавливаться после сбоя и выполнять нереализованные операции (в NT 4.0 не реализовано)
Драйверы имеют унифицированную модель интерфейса => диспетчер В/В не видит их структуру и детали реализации. При взаимодействии различных драйверов диспетчер играет роль посредника.
Драйверы могут быть:
- Однослойные (для последовательного порта и др.)
- Многослойные (для ЗУ большой емкости)
Пример многослойного драйвера – при работе через SCSI-интерфейс драйвер дисков передает запрос на драйвер SCSI, который реализует обработку. Запрос к дискам реализует драйвер SCSI.
Передача может быть:
- Асинхронной – более быстродействующий вариант и экономичный в плане ресурсов (всегда СВВ)
- Синхронный – проще в плане реализации
Win32 автоматически выбирает синхронный/асинхронный вариант взаимодействия.
Поскольку асинхронный способ позволяет существенно увеличить производительность пользовательских приложений, то по умолчанию для 1/3 сервисов установлен асинхронный режим. Тем не менее поток может сам решать каким способом передавать данные.
Синхронная процедура:
Приложение WriteFile | (описатель файла, параметры) | Read(…) (приложение) |
Подсистема Win32 | Вызов NT сервиса Запись в файл | Вернуть данные |
Диспетчер В/В | 1) проверка параметров 2) Создание IRP 3) Вызов драйвера устройства | Завершение IRP возврат |
Драйвер устройства | Направить запрос на устройство | обработка прерывания |
Устройство | Выполнить передачу данных | |
прерывание здесь ожидаем |
Асинхронная процедура:
Приложение WriteFile | (описатель файла, параметры) | передача упр-я | <ожидание> |
Подсистема Win32 | Вызов NT сервиса Запись в файл | wait (описатель файла); вернуть код завершения и В/В выполняется | возврат данных |
Диспетчер В/В | 4) проверка параметров 5) Создание IRP 6) Вызов драйвера устройства | возврат | 1) завершить IRP 2) установить описатель объекта-файла в сигнализир. состояние |
Драйвер устройства | Направить запрос на устройство | возврат | обработка прерывания |
Устройство | 1) выполнить передачу данных 2) перывание |
В асинхронной перевод файла в сигнальное состояние необходим для защиты данных (т.к. произошла смена контекста для другой работы).
Атрибут файла «совмещённый» (overlapped) – асинхронный режим (специальная реализация обмена).
Формат пакета IRP
Каждому потоку соответствует своя очередь IRP-пакетов. Это позволяет идентифицировать IRP-пакеты. При завершении потока очередь удаляется.
Управление очередью в соответствии с составом потока.
Структура драйвера
Всякий драйвер – независимый элемент ОС, который может быть динамически загружен или удален без изменения конфигурации ОС.
Составная часть | Назначение процедуры |
Процедура инициализации (1) | Выполняется диспетчером В/В при загрузке ОС. Создаются системные объекты для распознавания устройства и доступа к нему. |
Набор процедур распределения (2) | Главные функции, предоставляемые драйверами устройствам. Запрос В/В заставляет диспетчер В/В генерировать IRP и обращается к драйверу через процедуру распределения. |
Процедура запуска В/В (3) | Драйвер использует эту процедуру для начала передачи данных. Необязательная процедура характерна для физических устройств при передаче больших объемов. |
ISR Interrupt (4) | Прерывание от устройства. На момент выполнения приоритет RPL повышается. Сообразно ISR выполняет часть кода обработчиков. В соответствии с прерыванием эта часть кода может быть с повышенным приоритетом, а часть кода обработки является вторичной и выполняется посредством отлож. вызова DPC (ISR генерир. DPC). |
Процедура DPC (5) | Процедура обработки прерывания, которая выполняется при более низком, чем у IRQ приоритете. Выполняет большую часть обработки по обслуживанию прерывания. Это инициирует завершение В/В и запуск следующего запроса из очереди на обработку устройствами В/В. |
Процедура завершения (6) | Является посредником между драйверами нижнего и верхнего уровня. В ней хранится информация о возможных значениях, сбое или необходимости очистки при инициализации. |
Процедура отмены В/В (7) | Может быть не одной. Информация об активизации процедуры отмены хранится в IRP. |
Процедура выгрузки (8) | Освобождение системных ресурсов, которые используются драйвером. Затем диспетчер В/В удаляет драйвер из памяти. Драйвер может быть загружен/выгружен во время работы. |
Процедура протоколирования ошибок (9) | Информирование диспетчера В/В об ошибке, который помещает эту информацию в журнал ошибок. |
Минимальный драйвер должен содержать 3 процедуры:
Драйвер устройства:
(1), (2), (3), (4), (5), (6), (8) для многослойного драйвера
Проекционный файл В/В (mapped) – используется для загрузки исполняемой программы и кэширования файлов.
Совместно используется диспетчер В/В и диспетчер виртуальной памяти. Проекционный В/В позволяет рассматривать дисковый файл, как виртуальную память процесса. Проекционный В/В по сути использует диспетчер виртуальной памяти и менеджер подкачки.