Согласование скоростей обменаи кэширование данных

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

Разделение устройств и данных

Устройства ввода-вывода могут предоставляться процессам как в монопольное, так и в совместное (разделяемое) использование.

 

Программный интерфейс к устройствам

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

 

Поддержка широкого спектра драйверов

Драйвер должен поддерживать два типа интерфейсов:

■ интерфейс «драйвер-ядро» (Driver Kernel Interface, DKI) с модулями ядра ОС (модулями подсистемы ввода-вывода, системных вызовов, подсистем управления процессами и памятью и т. д.);.

■ интерфейс «драйвер-устройство» (Driver Device Interface, DDI) с контроллерами внешних устройств.

Интерфейс «драйвер-ядро» должен быть стандартизован в любом случае, а интерфейс «драйвер-устройство» имеет смысл стандартизировать тогда, когда подсистема ввода-вывода не разрешает драйверу непосредственно взаимодействовать с аппаратурой контроллера, а выполняет эти операции самостоятельно.

Для поддержки процесса разработки драйверов операционной системы обычно выпускается так называемый пакет DDK (Driver Development Kit), представляющий собой набор соответствующих инструментальных средств — библиотек, компиляторов и отладчиков.

 

Динамическая загрузка и выгрузка драйверов

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

Поддержка файловых систем

41!!!. Синхронный и асинхронный режимы

По отношению к программному модулю, запросившему операцию ввода-вывода, она может выполняться в синхронном или асинхронном режиме. Смысл этих режимов тот же, что и для рассмотренных ранее системных вызовов:

■ в синхронном режиме программный модуль приостанавливает свою работу до тех пор, пока операция ввода-вывода не будет завершена;

■ в асинхронном режиме программный модуль продолжает выполняться в мультипрограммной среде одновременно с операцией ввода-вывода.

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

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

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

■ пользовательский интерфейс ввода-вывода;

■ интерфейс с устройствами ввода-вывода;

■ интерфейс с другими подсистемами ОС;

■ внутренний интерфейс между компонентами подсистемы ввода-вывода.

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

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

 

42!!!. Первоначально термин «драйвер» применялся в более узком смысле, чем в настоящее время:

Драйвер — это программный модуль, который:

■ входит в состав ядра операционной системы, работая в привилегированном режиме;

■ непосредственно управляет внешним устройством, взаимодействуя с его контроллером с помощью команд ввода-вывода компьютера;

■ обрабатывает прерывания от контроллера устройства;

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

■ взаимодействует с другими модулями ядра ОС с помощью строго оговоренного интерфейса, описывающего формат передаваемых данных, структуру буферов, способы включения драйвера в состав ОС, способы вызова драйвера, набор общих процедур подсистемы ввода-вывода, которыми драйвер может пользоваться, и т. п.

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

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

Несколько драйверов, управляющих одним устройством, но на разных уровнях, можно рассматривать как набор отдельных драйверов или как один многоуровневый драйвер.

Драйверы могут быть разделены на два больших класса:

■ Блок-ориентированные драйверы управляют устройствами прямого доступа, хранящих информацию в блоках фиксированного размера, каждый из которых имеет собственный адрес. Самое распространенное внешнее устройство прямого доступа — диск. Адресуемость блоков приводит к тому, что для устройств прямого доступа появляется возможность кэширования данных в оперативной памяти, это обстоятельство значительно влияет на общую организацию ввода-вывода для блок-ориентированных драйверов.

■ Байт-ориентированные драйверы работают с устройствами, которые не адресуемы и не позволяют производить операцию поиска данных, они генерируют или потребляют последовательности байтов. Примерами таких устройств, которые также называют устройствами последовательного доступа, служат терминалы, строчные принтеры, сетевые адаптеры.

Для байт-ориентированного устройства невозможно разработать блок-ориентированный драйвер. Однако блок-ориентированным устройством можно управлять и с помощью байт-ориентированного драйвера. Деление всех драйверов на блок-ориентированные и байт-ориентированные оказывается полезным для структурирования подсистемы управления вводом-выводом