[Previous] [Next]

Драйверы: крупный план. Unix-Linux, DOS-Windows

Строго говоря, драйвером считается фрагмент кода операционной системы, который позволяет ей обращаться к аппаратуре. Не вполне конкретный термин "аппаратура" обозначает здесь как неотъемлемые части компьютера (например, наборы микросхем на материнских платах современных персональных компьютеров), так и вполне автономные устройства (как, скажем, "древние" устройства считывания с перфокарт, редко размещавшиеся в одной комнате с процессорной стойкой).

Концепция драйвера как отдельного сменного модуля оформилась не сразу. Некоторые версии UNIX и по сию пору практикуют полную перекомпиляцию ядра при замене какого-либо драйвера, что совершенно не похоже на обращение с драйверами в Linux, Windows и MS DOS. Кстати, именно MS DOS ввела в массовое обращение понятие драйвера, как легко сменяемой насадки, позволяющей моментально (сразу после очередной перезагрузки) улучшить качество жизни пользователя: шрифты на мониторе радуют глаз, емкость дискеты возросла вдвое, в принтере наконец-то поселилась кириллица и т.п.

Касаясь характерных черт драйвера (работающего с полномочиями компонента ядра) для разных операционных систем - именно, Windows и Linux - остановимся на трех неслучайных совпадениях.

Наблюдение 1. В операционных системах MS DOS, Windows, Unix и всех клонах Linux принят способ работы с драйверами как с файлами. То есть при доступе к драйверу используются функции либо совпадающие (лексически), либо весьма похожие на функции для работы с файлами (open, close, read, write, CreateFile...).

Данный порядок неудивителен для систем юниксоидного ряда, поскольку в них вся действительность воспринимается в виде файлов (что является изначальной концепцией данной ветви операционных систем). Например, директорию (каталог файлов) можно открыть как файл и считывать оттуда блоки данных, соответствующие информации о каждом хранящемся в этой директории файле. В директории /dev/ можно открыть файл, соответствующий мышке и считывать постепенно байты данных, появляющиеся в нем в точном соответствии с ее перемещениями.

Как ни удивительно покажется это рядовому пользователю операционной системы Windows, но и в ней предлагается точно такой же механизм. Для доступа к драйверу из своего приложение пользователь прибегает к помощи функции CreateFile (это могла бы быть функция OpenFile, но это название морально устарело, поскольку использовалась в старых 16-тиразрядных версиях Windows). Правда, имя файла, который предполагается "открыть", выглядит странно, и на жестком диске такого файла отыскать невозможно - он существует лишь в недрах операционной системы и выглядит, например, как "\\\\.\\myDevice". (Операционная система понимает его как символьную ссылку для идентификации конкретного драйвера, привлекаемого к работе.) И хотя дальнейшие операции, сформулированные создателем пользовательского приложения как вызовы read()-write(), все-таки преобразуются операционной системой в специальные запросы к драйверу, необходимо признать: формально процесс похож на работу с файлом.

Наблюдение 2. Драйверы стали легко заменяемой запасной частью в операционной системе. Если раньше и были различия между продуктами Microsoft и юниксоидными системами (драйверы в операционных системах Microsoft изначально были "подвижно-сменными", но в UNIX и ранних версиях Linux при их замене надо было заново выполнять перекомпиляцию ядра), то сейчас такие различия исчезли. При сохранении некоторых особенностей инсталляции, драйверы теперь повсеместно могут быть удалены/добавлены в систему редактированием одной записи в специальных системных файлах. Более того, загрузка "по требованию" (по запросу пользовательской программы) становится практически общей чертой Windows/Unix/Linux. Даже операционные системы реального времени, например, QNX также используют методику сменных драйверов.

Наблюдение 3. Концепция существования режима ядра (с большими функциональными возможностями и относительной бесконтрольности) и пользовательского режима (с жестким контролем со стороны системы) присутствует в Windows/Unix/Linux с незапамятных времен. Если внимательно посмотреть на то, как в Linux реализуется драйвер, то увидим, что это всего лишь модуль ядра, который имеет некое (дополнительное) отражение в виде файла в директории /dev/. Если посмотреть теперь на драйвер (режима ядра) в операционной системе Windows, то становится понятно: это не просто драйвер, это возможность войти в режим ядра со своим программным кодом. От судьбы не уйдешь. Microsoft не предоставила явной возможности создавать модули ядра, однако закрыть эту брешь в виде драйверов - невозможно! В великолепной книге Свена Шрайбера "Недокументированные возможности Windows 2000" как раз эксплуатируется эта "черта личности" драйвера Windows.

Завершая мини-экскурс в сравнительный анализ драйверов разных популярных ОС, нельзя не упомянуть и об общем для всех систем механизме воздействия на драйвер при помощи IOCTL запросов (работа с IOCTL в Windows будет подробно рассмотрена в главе 8).