Скачиваний:
71
Добавлен:
02.05.2014
Размер:
253.95 Кб
Скачать

Глава 6. Управление вводом-выводом

6.1. Виртуализация устройств и структура драйвера

Управление вводом-выводом в полной мере воплощает в себе определение "ОС снаружи": ОС конструирует ресурсы высокого уровня – виртуальные устройства – и предоставляет пользователю интерфейс для работы с ними. Программисты, начинавшие работу в среде MS DOS, привыкли к доступности средств прямого управления вводом-выводом для любой программы, но в многозадачных ОС о такой доступности для прикладной программы может идти речь только в исключительных случаях, а в многопользовательских ОС она исключается вообще.

Можно в общем случае определить четыре метода, которые могут использоваться ОС для конструирования виртуальных устройств (виртуализации):

  • метод закрепления или выделения (allocation);

  • метод разделения (sharing);

  • метод накопления или спулинга (spooling);

  • метод моделирования (simulation).

Одна и та же ОС может использовать разные методы виртуализации для разных устройств.

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

Метод разделения применим к устройством, ресурс которых является делимым. В этом случае ресурс устройства разбивается на части, каждая из которых закрепляется за одним процессом. Примером применения метода могут служить минидиски в ОС VM/370 [28]: все пространство диска разбивается на участки, каждый из которых выглядит для процесса как отдельный том. Можно, например, разделять между процессами и экран видеотерминала. Зафиксированная часть устройства является также монопольным ресурсом и разделение лишь частично снимает остроту проблем управления таким ресурсом. Возможность дробления устройства предполагает внутреннюю адресацию в устройстве (адрес на диске, адрес в видеопамяти). По аналогии с адресацией в памяти процесс и здесь работает с виртуальными адресами в виртуальном устройстве, а ОС транслирует их в реальные адреса в реальном устройстве.

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

Метод моделирования не связан с реальными устройствами вообще. Устройство моделируется ОС чисто программными методами. Естественным применением этого метода является отработка приемов работы с устройствами, отсутствующими в конфигурации данной вычислительной системы. Часто ОС удобно представлять некоторые свои ресурсы как метафоры (подобия) устройств – это также моделируемые устройства. Так, в VM/ESA обмен данными между виртуальными машинами ведется через виртуальный адаптер, метафорой устройства можно также считать межпрограммный канал (pipe), реализованный во многих современных ОС.

При любом методе виртуализации ОС является "прослойкой" между процессами и реальными устройствами. Эту функцию выполняют входящие в состав ОС драйверы устройств. К драйверам обращаются и другие модули ОС, и процессы пользователя, причем последние, как правило, не непосредственно, а через библиотеки вызовов, предоставляющие более удобный API. В некоторых случаях ОС может предоставить пользователю интерфейс, обладающий высокой степенью подобия с интерфейсом реального устройства, но и в этом случае ОС, даже применяя метод выделения, производит обработку управляющих воздействий, сформированных процессом: проверку правильности команд, трансляцию адресов памяти, адресов устройств и адресов в устройствах и т.п.

Модули ОС, которые осуществляют трансляцию однотипных для всех устройств обращений к ним из процессов и из других модулей ОС в специфические для устройства управляющие воздействия и управляют выполнением этих воздействий, называются драйверами. (Мы не согласны с теми авторами, которые называют драйверами любые программы управления вводом-выводом, драйверы в нашем понимании обязательно включаются в состав ОС и обязательно соответствуют спецификациям данной ОС.) Каждому типу устройства соответствует свой драйвер. Драйвер устройства имеет два основных уровня, как показано на рисунке 6.1. Первый (верхний) уровень принимает системные вызовы от процессов и формирует на основании каждого вызова запрос. Этот же уровень выстраивает запросы в очередь и поддерживает упорядоченность этой очереди в соответствии с принятой дисциплиной обслуживания. Второй (нижний) уровень драйвера выбирает из очереди запрос и обслуживает его: формирует управляющие воздействия и передает их на устройство, обрабатывает прерывания от устройства и сообщает ядру ОС о наступлении событий, связанных с вводом-выводом.

Очевидно, что нижний уровень драйвера должен иметь возможность выполнять привилегированные команды – команды ввода-вывода и т.п. Можно назвать три варианта обеспечения такой возможности. Вариант первый – включение драйверов в ядро ОС. При этом достигается высокая эффективность функционирования драйверов, но изменение состава драйверов требует перекомпоновки ядра. Второй вариант – выполнение драйверов в виде отдельных модулей, функционирующих в режиме ядра. Этот вариант позволяет изменять состав драйверов без изменения ядра ОС, но в принципе снижает надежность системы, так как новые модули, функционирующие в режиме ядра, могут являться источником фатальных ошибок. Наконец, третий вариант – драйверы выполняются в виде модулей режима процесса, но ОС предоставляет для них сервисные системные вызовы, выполняющие для драйверов операции режима ядра. Этот вариант допускает изменение драйверов и не снижает надежность, но является несколько менее эффективным.

Во многих современных ОС применяется не двух-, а многоуровневая структура драйверов. Нижний уровень классического двухуровневого драйвера сохраняется и называется аппаратным драйвером. Функции же верхнего уровня разделяются между драйверами нескольких слоев. Каждый более высокий уровень выполняет более абстрактную обработку данных и в меньшей степени зависит от конкретного устройства. Каждый уровень представляет собой отдельный драйвер и может меняться независимо от других. Многоуровневая структура позволяет минимизировать изменения состава драйверов при изменении состава устройств.

Соседние файлы в папке Системное программирование и операционные системы