Какие функции возлагаются на драйвер периферийного устройства
Для обмена данными между компьютером и периферийным устройством (ПУ) в компьютере предусмотрен внешний интерфейс (рис. 1.6), то есть набор проводов, соединяющих компьютер и периферийное устройство, а также набор правил обмена информацией по этим проводам (иногда вместо термина интерфейс употребляется термин протокол - подробней об этих важных терминах мы еще поговорим). Примерами интерфейсов, используемых в компьютерах, являются параллельный интерфейс Centronics, предназначенный, как правило, для подключения принтеров, и последовательный интерфейс RS-232C, через который подключаются мышь, модем и много других устройств. Интерфейс реализуется со стороны компьютера совокупностью аппаратных и программных средств: контроллером ПУ и специальной программой, управляющей этим контроллером, которую часто называют драйвером соответствующего периферийного устройства.
Со стороны ПУ интерфейс чаще всего реализуется аппаратным устройством управления, хотя встречаются и программно-управляемые периферийные устройства.
Программа, выполняемая процессором, может обмениваться данными с помощью команд ввода/вывода с любыми модулями, подключенными к внутренней шине компьютера, в том числе и с контроллерами ПУ.
Периферийные устройства могут принимать от компьютера как данные, например байты информации, которую нужно распечатать на бумаге, так и команды управления, в ответ на которые ПУ может выполнить специальные действия, например перевести головку диска на требуемую дорожку или же вытолкнуть лист бумаги из принтера. Периферийное устройство использует внешний интерфейс компьютера не только для приема информации, но и для передачи информации в компьютер, то есть обмен данными по внешнему интерфейсу, как правило, является двунаправленным. Так, например, даже принтер, который по своей природе является устройством вывода информации, возвращает в компьютер данные о своем состоянии.
Контроллеры ПУ принимают команды и данные от процессора в свой внутренний буфер, который часто называется регистром или портом, затем выполняют необходимые преобразования этих данных и команд в соответствии с форматами, понятными ПУ, и выдают их на внешний интерфейс.
Распределение обязанностей между контроллером и драйвером ПУ может быть разным, но обычно контроллер выполняет набор простых команд по управлению ПУ, а драйвер использует эти команды, чтобы заставить устройство совершать более сложные действия по некоторому алгоритму. Например, контроллер принтера может поддерживать такие элементарные команды, как «Печать символа», «Перевод строки», «Возврат каретки» и т. п. Драйвер же принтера с помощью этих команд организует печать строк символов, разделение документа на страницы и другие более высокоуровневые операции. Для одного и того же контроллера можно разработать различные драйверы, которые будут управлять данным ПУ по-разному - одни лучше, а другие хуже - в зависимости от опыта и способностей программистов, их разработавших.
Рис. 1.6. Связь компьютера с периферийным устройством
Рассмотрим схему передачи одного байта информации от прикладной программы на периферийное устройство. Программа, которой потребовалось выполнить обмен данными с ПУ, обращается к драйверу этого устройства, сообщая ему в качестве параметра адрес байта памяти, который нужно передать. Драйвер загружает значение этого байта в буфер контроллера ПУ, который начинает последовательно передавать биты в линию связи, представляя каждый бит соответствующим электрическим сигналом. Чтобы устройству управления ПУ стало понятно, что начинается передача байта, перед передачей первого бита информации контроллер ПУ формирует стартовый сигнал специфической формы, а после передачи последнего информационного бита - столовый сигнал. Эти сигналы синхронизируют передачу байта.
Кроме информационных бит, контроллер может передавать бит контроля четности для повышения достоверности обмена. Устройство управления, обнаружив на соответствующей линии стартовый бит, выполняет подготовительные действия и начинает принимать информационные биты, формируя из них байт в своем приемном буфере. Если передача сопровождается битом четности, то выполняется проверка правильности передачи: при правильно выполненной передаче в соответствующем регистре устройства управления устанавливается признак завершения приема информации.
Обычно на драйвер возлагаются наиболее сложные функции протокола (например, подсчет контрольной суммы последовательности передаваемых байтов, анализ состояния периферийного устройства, проверка правильности выполнения команды). Но даже самый примитивный драйвер контроллера должен поддерживать как минимум две операции: «Взять данные из контроллера в оперативную память» и «Передать данные из оперативной памяти в контроллер».
Существуют как весьма специализированные интерфейсы, пригодные для подключения узкого класса устройств (например, графических мониторов высокого разрешения фирмы Vista), так и интерфейсы общего назначения, являющиеся стандартными и позволяющие подключать различные периферийные устройства. Примером такого интерфейса является интерфейс RS-232C, который поддерживается многими терминалами, принтерами, графопостроителями, манипуляторами типа «мышь» и многими другими устройствами.
Как уважаемый хабрапользователь наверняка знает, «драйвер устройства» — это компьютерная программа управляющая строго определенным типом устройства, подключенным к или входящим в состав любого настольного или переносного компьютера.
Основная задача любого драйвера – это предоставление софтового интерфейса для управления устройством, с помощью которого операционная система и другие компьютерные программы получают доступ к функциям данного устройства, «не зная» как конкретно оно используется и работает.
Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.
Любой драйвер является зависимым от самого устройства и специфичен для каждой операционной системы. Обычно драйверы предоставляют схему прерывания для обработки асинхронных процедур в интерфейсе, зависимом от времени ее исполнения.
Любая операционная система обладает «картой устройств» (которую мы видим в диспетчере устройств), для каждого из которых необходим специфический драйвер. Исключения составляют лишь центральный процессор и оперативная память, которой управляет непосредственно ОС. Для всего остального нужен драйвер, который переводит команды операционной системы в последовательность прерываний – пресловутый «двоичный код».
Как работает драйвер и для чего он нужен?
Основное назначение драйвера – это упрощение процесса программирования работы с устройством.
Он служит «переводчиком» между хардовым (железным) интерфейсом и приложениями или операционными системами, которые их используют. Разработчики могут писать, с помощью драйверов, высокоуровневые приложения и программы не вдаваясь в подробности низкоуровневого функционала каждого из необходимых устройств в отдельности.
Как уже упоминалось, драйвер специфичен для каждого устройства. Он «понимает» все операции, которые устройство может выполнять, а также протокол, с помощью которого происходит взаимодействие между софтовой и железной частью. И, естественно, управляется операционной системой, в которой выполняет конкретной приложение либо отдельная функция самой ОС («печать с помощью принтера»).
Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).
Как создается драйвер устройства
Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.
При создании драйвера для Линукса, вам необходимо знать не только тип шины и ее адрес, но и схематику самого устройства, а также весь набор электрических прерываний, в ходе исполнения которых устройство отдает результат драйверу.
Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.
И чем драйвер не является
Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:
- Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
- Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.
Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.
Вряд ли пользователь домашнего ПК заинтересуется тем, чтобы блокировать устройства на своем ПК. Но если дело касается корпоративной среды, то все становится иначе. Есть пользователи, которым можно доверять абсолютно во всем, есть такие, которым можно что-то делегировать, и есть те, кому доверять совсем нельзя. Например, вы заблокировали доступ к Интернету одному из пользователей, но не заблокировали устройства этого ПК. В таком случае пользователю достаточно просто принести USB-модем, и Интернет у него будет. Т.е. простым блокированием доступа к Интернету дело не ограничивается.
Однажды примерно такая задача и стояла передо мной. Времени на поиск каких-либо решений в Интернете не было, да и они, как правило, небесплатные. Поэтому мне было проще написать такой драйвер, и его реализация отняла у меня один день.
Структура DRIVER_OBJECT
Для каждого загруженного драйвера система формирует структуру DRIVER_OBJECT. Этой структурой система активно пользуется, когда отслеживает состояние драйвера. Также драйвер отвечает за ее инициализацию, в частности за инициализацию массива MajorFunction. Этот массив содержит адреса обработчиков для всех запросов, за которые драйвер может отвечать. Следовательно, когда система будет посылать запрос драйверу, она воспользуется этим массивом, чтобы определить, какая функция драйвера отвечает за конкретный запрос. Ниже представлен пример инициализации этой структуры.
Такая инициализация обычно выполняется при вызове системой точки входа драйвера, прототип которой изображен ниже.
Как видно из примера, сначала весь массив MajorFunction инициализируется одним и тем же обработчиком. В реальности типов запросов больше, чем в примере. Поэтому предварительно весь массив инициализируется так, чтобы запросы, которые не поддерживаются драйвером, обрабатывались корректно. Например, завершались с ошибкой. После инициализации массива обычно инициализируются обработчики для тех запросов, за которые драйвер отвечает.
Также инициализируется поле DriverUnload структуры, которое содержит адрес обработчика, отвечающего за завершение работы драйвера. Это поле может быть оставлено непроинициализированным, в таком случае драйвер становится невыгружаемым.
Обратите внимание на то, что в поле DriverExtension->AddDevice устанавливается адрес обработчика, который вызывается всякий раз, когда система обнаруживает новое устройство, за работу которого драйвер отвечает. Данное поле может быть оставлено непроинициализированным, в таком случае драйвер не сможет обрабатывать это событие.
Структура DEVICE_OBJECT
Структура DEVICE_OBJECT представляет ту или иную функциональность драйвера. Т.е. эта структура может представлять физическое устройство, логическое устройство, виртуальное устройство или просто некий функционал, предоставляемый драйвером. Поэтому когда система будет посылать запросы, то в самом запросе она будет указывать адрес этой структуры. Таким образом, драйвер сможет определить, какой функционал от него запрашивается. Если не использовать такую модель, тогда драйвер может обрабатывать только какую-нибудь одну функциональность, а в современном мире это недопустимо. Прототип функции, которая обрабатывает конкретный запрос, приведена ниже.
Массив MajorFunction ранее упомянутой структуры DRIVER_OBJECT содержит адреса обработчиков именно с таким прототипом.
Сама структура DEVICE_OBJECT всегда создается драйвером при помощи функции IoCreateDevice. Если система посылает запрос драйверу, то она всегда направляет его какому-либо DEVICE_OBJECT, как это следует из вышепредставленного прототипа. Также, прототип принимает второй параметр, который содержит адрес IRP-структуры. Эта структура описывает сам запрос, и она существует в памяти до тех пор, пока драйвер не завершит его. Запрос отправляется драйверу на обработку при помощи функции IoCallDriver как системой, так и другими драйверами.
Также со структурой DEVICE_OBJECT может быть связано имя. Таким образом, этот DEVICE_OBJECT может быть найден в системе.
Фильтрация
Фильтрация являет собой механизм, который позволяет перехватывать все запросы, направленные к конкретному DEVICE_OBJECT. Чтобы установить такой фильтр, необходимо создать другой экземпляр DEVICE_OBJECT и прикрепить его к DEVICE_OBJECT, запросы которого необходимо перехватывать. Прикрепление фильтра выполняется посредством функции IoAttachDeviceToDeviceStack. Все DEVICE_OBJECT, прикрепленные к перехватываемому DEVICE_OBJECT, вместе с ним формируют так называемый стек устройства, как это изображено ниже.
Стрелкой изображено продвижение запроса. Сначала запрос будет обрабатываться драйвером верхнего DEVICE_OBJECT, затем драйвером среднего и, в конце концов, управление на обработку запроса получит драйвер целевого DEVICE_OBJECT. Также нижний DEVICE_OBJECT называется дном стека, т.к. он ни к кому не прикреплен.
Наличие такого механизма позволяет добавлять функционал, которого нет изначально в драйверах. Например, таким образом, без доработки файловой системы FAT, поставляемой в Windows, можно добавить проверку прав доступа к файлам этой файловой системы.
PnP менеджер
PnP менеджер отвечает за диспетчеризацию устройств всей системы. В его задачи входит обнаружение устройств, сбор информации о них, загрузка их драйверов, вызов этих драйверов, управление аппаратными ресурсами, запуск и остановка устройств и их удаление.
Когда драйвер той или иной шины обнаруживает устройства на своих интерфейсах, то для каждого дочернего устройства он создает DEVICE_OBJECT. Этот DEVICE_OBJECT также называют Physical Device Object или PDO. Затем посредством функции IoInvalidateDeviceRelations он уведомляет PnP менеджер о том, что произошли изменения на шине. В ответ на это PnP менеджер посылает запрос с minor кодом IRP_MN_QUERY_DEVICE_RELATIONS с целью запросить список дочерних устройств. В ответ на этот запрос драйвер шины возвращает список PDO. Ниже изображен пример такой ситуации.
Как отражено на рисунке, в данном примере в качестве шины выступает драйвер USB-хаба. Конкретные DEVICE_OBJECT стека устройства этого хаба не изображены для краткости и с целью сохранения последовательности пояснений.
Как только PnP менеджер получит список всех PDO, он по отдельности соберет всю необходимую информацию об этих устройствах. Например, будет послан запрос с minor кодом IRP_MN_QUERY_ID. Посредством этого запроса PnP менеджер получит идентификаторы устройства, как аппаратные, так и совместимые. Также PnP менеджер соберет всю необходимую информацию о требуемых аппаратных ресурсах самим устройством. И так далее.
После того, как вся необходимая информация будет собрана, PnP менеджер создаст так называемую DevNode, которая будет отражать состояние устройства. Также PnP создаст ветку реестра для конкретного экземпляра устройства или откроет существующую, если устройство ранее подключалось к ПК.
Следующая задача PnP — это запуск драйвера устройства. Если драйвер не был ранее установлен, тогда PnP будет ожидать установки. Иначе, при необходимости, PnP загрузит его и передаст ему управление. Ранее упоминалось, что поле DriverExtension->AddDevice структуры DRIVER_OBJECT содержит адрес обработчика, который вызывается всякий раз, когда система обнаруживает новое устройство. Прототип этого обработчика изображен ниже.
В задачу обработчика входит создание DEVICE_OBJECT и его прикрепление к PDO. Прикрепленный DEVICE_OBJECT также называют Functional Device Object или FDO. Именно этот FDO и будет отвечать за работу устройства и представление его интерфейсов в системе. Ниже представлен пример, когда PnP завершил вызов драйвера, отвечающего за работу устройства.
В этот момент стеки устройств полностью сформированы и готовы к работе. Поэтому PnP посылает запрос с minor кодом IRP_MN_START_DEVICE. В ответ на этот запрос все драйвера стека устройства должны подготовить устройство к работе. И если в этом процессе не возникло проблем, тогда запрос завершается успешно. В противном случае, если любой из драйверов не может запустить устройство, тогда он завершает запрос с ошибкой. Следовательно, устройство не будет запущено.
Также, когда драйвер шины определяет, что произошли изменения на шине, он посредством функции IoInvalidateDeviceRelations уведомляет PnP о том, что следует заново собрать информацию о подключенных устройствах. В этот момент драйвер не удаляет ранее созданный PDO. Просто при получении запроса с minor кодом IRP_MN_QUERY_DEVICE_RELATIONS он не включит этот PDO в список. Затем PnP на основании полученного списка опознает новые устройства и устройства, которые были отключены от шины. PDO отключенных устройств драйвер удалит тогда, когда PnP пошлет запрос с minor кодом IRP_MN_REMOVE_DEVICE. Для драйвера этот запрос означает, что устройство более никем не используется, и оно может быть безопасно удалено.
Суть решения
Как следует из примера, мы создаем DEVICE_OBJECT и прикрепляем его к PDO. Таким образом, мы будем перехватывать все запросы, направленные к USB-шине.
В нашу задачу входит перехватывать запросы с minor кодом IRP_MN_START_DEVICE. Код обработчика этого запроса изображен ниже.
Как изображено на рисунке, обработчик вызывает функцию UsbIsDeviceAllowedToWork. Эта функция выполняет все необходимые проверки, чтобы определить, разрешено ли устройству работать. В первую очередь функция позволяет всегда работать хабам и композитным устройствам, клавиатурам и мышам. А также тем устройствам, которые находятся в списке разрешенных. Если функция возвращает неуспешный код возврата, тогда запрос завершается с ошибкой. Таким образом, работа устройства будет заблокирована.
Обратите внимание: функция определяет, является ли устройство хабом или композитным устройством. Это необходимо потому, что, как уже было упомянуто, класс устройств, который используется для хабов и хост контроллеров, используется не только этими устройствами. А нам в первую очередь необходимо контролировать дочерние устройства только хабов, хост контроллеров и композитных устройств. Т.е. для хабов и композитных устройств дополнительно перехватывается запрос перечисления дочерних устройств, на этом этапе, важно также прикрепить ко всем дочерним устройствам фильтр, и этот фильтр будет нижним. В противном случае контроль над дочерними устройствами будет потерян.
Все упомянутые определения выполняются на основе идентификаторов устройств.
Заключение
Несмотря на свою простоту в моем случае данный драйвер достаточно эффективно решает поставленную задачу. Хотя из недостатков следует выделить обязательную перезагрузку после того, как список разрешенных устройств будет обновлен. Чтобы устранить этот недостаток, драйвер потребуется несколько усложнить. Еще большим недостатком является полное блокирование устройства, а не частичное. Описание, представленное выше, не раскрывает всех деталей реализации. Сделано это было намеренно, и упор был сделан больше на саму концепцию. Желающие разобраться во всем до конца могут ознакомиться с исходным кодом.
1. Какая информация передается по каналу, связывающему внешние интерфейсы компьютера и периферийного устройства? Команды для управления периферийным устройством, данные о состоянии периферийного устройства, а также данные ввода-вывода.
3. Какие задачи решает ОС при обмене с периферийным устройством?
4. Какие функции возлагаются на драйвер периферийного устройства?
5. Дайте определение понятия �топология�.
6. К какому типу топологии можно отнести структуру, образованную тремя связанными друг с другом узлами (в виде треугольника)? Полносвязная, кольцевая.
7. К какому типу топологии можно отнести структуру, образованную четырьмя связанными друг с другом узлами (в виде квадрата)? Ячеистая, кольцевая.
8. К какому типу топологии можно отнести структуру, образованную тремя последовательно соединенными друг с другом узлами (последний не связан с первым)? Ячеистая, звезда.
9. Частным случаем какой топологии является общая шина:
10. Какая из известных топологий обладает повышенной надежностью? Кольцо, так как информация может передаваться в двух направлениях.
11. Какой тип топологии наиболее распространен сегодня в локальных сетях? Иерархическая звезда (или дерево).
12. Какие требования предъявляются к системе адресации?
13. К какому типу можно отнести следующие адреса:
� 20-34-а2-00-с2-27;������������� числовой� плоский адрес
� 128.145.23.170.������� числовой, иерархический адрес
14. Чем неравномерный поток данных отличается от равномерного?
15. Какие параметры передаваемых данных могут служить признаком потока? Адрес источника, адрес назначения, метка, тип приложения и другие
16. Какие из утверждений о маршруте, на ваш взгляд, не всегда верны:
� маршрут � это последовательность промежуточных узлов (интерфейсов), которые проходят данные по пути от отправителя к получателю;
� при определении маршрута всегда выбирается один из нескольких возможных путей; это утверждение верно не всегда, т.к. очень часто существует единственный маршрут
� каждый маршрут назначается для определенного потока данных;
� из нескольких возможных маршрутов всегда выбирается оптимальный. это утверждение верно не всегда, т.к. очень часто выбранный маршрут является лишь рациональным, то есть близким к оптимальному.
17. Опишите основные подходы и критерии, используемые при выборе маршрута. В качестве критериев �оптимальности могут выступать, например, номинальная пропускная способность �и загруженность каналов связи; задержки, вносимые каналами; количество промежуточных транзитных узлов; надежность каналов и транзитных узлов. На выбор маршрута могут также влиять особые требования к сети со стороны различных типов приложений, предположения о пиковых нагрузках на некоторые каналы сети, соображения безопасности и многие другие факторы.
18. Какие из этих утверждений могут быть в некоторых случаях верными:
� маршруты фиксируются в коммутаторах путем жесткого соединения пар интерфейсов; да.
� маршруты определяются администратором и заносятся вручную в специальную таблицу; да
� таблица маршрутов строится автоматически сетевым программно-аппаратным обеспечением; да
� для каждого коммутатора строится своя таблица маршрутов, которая на нем и хранится. да
19. Какое из этих устройств можно назвать коммутатором:
� электрический выключатель; да
� автоматическая телефонная станция; да
� �ни одно из названных.
20. Какие методы используются при мультиплексировании? Р азделение времени и � частотное разделение � канала.
21. Объясните различия между разделением среды передачи и мультиплексированием.
22. Опишите, какие основные задачи нужно решить, чтобы обеспечить информационное взаимодействие любой пары абонентов в коммуникационной сети любого типа. (1) Определение потоков и соответствующих маршрутов; (2) фиксация маршрутов в конфигурационных параметрах и таблицах сетевых устройств; (3) распознавание потоков и передача данных между интерфейсами одного устройства; (4) мультиплексирование /демультиплексирование потоков; (5) разделение среды передачи
23. Как представление общего городского трафика в виде нескольких различных потоков позволяет рационализировать управление городским транспортом?
24. Пусть в сети существует несколько маршрутов между двумя конечными узлами А и B. Перечислите достоинства и недостатки следующих вариантов передачи данных между этими узлами:
� использовать все имеющиеся маршруты для параллельной передачи данных;
� передавать все данные по одному оптимальному по некоторому критерию маршруту;
� использовать несколько маршрутов из набора всех возможных маршрутов и разделять между ними передаваемые данные.
Какое правило можно применить для определения маршрута передачи очередного пакета в последнем из перечисленных случаев?
Это системная программа, которая под управлением ОС выполняет все операции с конкретным периферийным устройством.
Перед драйверами стоят две задачи:
1. Обеспечить стандартное обращение к любому устройству, скрывая от остальных частей системы специфические особенности этого устройства.
2. Добиться максимально эффективного использования всех функциональных возможностей конкретных устройств.
В большинстве ОП различают как минимум две разных типа драйверов: для блочных и для символьных устройств. Обращаясь к драйверу, ОС указывает функцию, которую требуется выполнить. Список этих функций общий для драйверов различных устройств, при этом каждый драйвер может реализовать только те функции, которые имеют смысл для данного устройства. Например, для блочных устройств – функция форматирования, для символьных устройств ввода – функция проверки очередного символа без изъятия его из входного потока. Для того что бы учесть все разнообразие возможных операций в число функций драйвера вводят такую операцию, как выполнение специальных функций.
К наиболее важным функциям драйвера относятся следующее:
· Открытие устройства – как минимум при этом увеличивается счетчик текущих обращений к устройствам, что позволяет ставить обращения к устройствам в очередь, если устройство занято.
· Закрытие устройства – обратное «открытию устройства».
· Обработка прерывания – выполняется ввод или вывод очередной порции данных, когда устройство переходит в состояние готовности.
· Опрос устройства – эта функция выполняется для тех устройств, которые не генерируют прерывание.
· Вызов стратегии – это способ выполнения операций ввода-вывода характерные для блочных устройств.
· Выполнение специальных функций –
Типичный драйвер устройство содержит как минимум три основных устройства:
1. Заголовок драйвера – содержит различную информацию о данном драйвере и об управляемом устройстве. Сюда может включаться имя, тип устройства, число однотипных устройств, объем памяти устройства и т.д. Заголовок так же содержит адреса блока стратегии и блока прерывания.
2. Блок стратегии – прием заявок на выполнение операции, введение очереди заявок, а так же запуск операции и ее завершение. Заявка на выполнение операции – стандартная запись, формируемая системой перед обращением драйверов. Она содержит код требуемых функций драйверов. Адрес данных в памяти и на устройстве, объем передаваемых данных. Заявка так же содержит поле, в которое драйвер должен был записать код завершения операции.
3. Блок прерывания – система его вызывает, когда получает сигнал прерывания от устройства. Закончив выполнения заявки, данный блок возвращает управление блоку стратегии для завершения операции.
Помимо трех основных блоков, в разных ОС, драйверы содержат блок инициализации, блок изменения параметров драйверов и т.д.
Усложнение периферийных устройств и самих операционных систем сделала актуальной многоуровневую схему использования драйверов. По этой схеме помимо использования низкоуровневого драйвера аппаратуры допускается еще создание высокоуровневых драйверов лежащих между драйверами аппаратуры и остальной части ОС. Высокоуровневый драйвер получает заявку ОС, преобразуя данные тем или иных образов и, для дальнейшей работы, вызывает низкоуровневый драйвер. Высокоуровневый драйвер не содержит блока прерывания.
Несмотря на стандартизацию структуры, можно выделить несколько спец типов драйверов, отличающихся функциональным назначением.
Ø Драйверы GDI – этот драйвер представляет собой высокоуровневый драйвер графических устройств. Он выполняет трансляцию графических вызовов ОС, преобразуя их в команды, выполняющие соответствующие команды на конкретном устройстве, а затем, выдача этих команд на устройство выполняется уже низкоуровневым драйвером.
Ø Драйверы виртуализации устройств – служат для того, что бы разделять устройства между процессами, создавая иллюзию того, что процесс монопольно владеет устройством. На самом деле драйвер организует очередь заявок о процессах, переключает устройство в нужный для очередного процесса режим.
Читайте также: