3. Обслуживание ввода-вывода

Режимы управления ввода-вывода

Операция ввода-вывода может выполняться по отношению к программному модулю в двух режимах:

1. синхронном – программный модуль приостанавливает свою рабо­ту до тех пор, пока операция ввода-вывода не будет завершена, что показано на рисунке 2.9, а. Так выполняются системные вызовы;

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

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

Рисунок 2.9, а – Синхронное выполнение операции ввода-вывода.

Рисунок 2.9, б – Асинхронное выполнение операции ввода-вывода.

Рисунок 2.10 – Обозначения процедур на рисунках 2.9, а и б.

Виртуальные устройства

Специальные файлы, называемые иногда виртуальными, являются удобным унифици­рованным представлением устройств ввода-вывода.

Понятие специального файла появилось в операционной системе UNIX. Специ­альный файл всегда связан с некоторым устройством ввода-вывода и представ­ляет его для остальной части операционной системы и прикладных процессов в виде неструктурированного набора байт. Со специальным файлом можно работать так же, как и с обычным. Для этого используются те же системные вызовы: open, create, read, write и close.

Для устройств прямого доступа имеет смысл указатель текущего положе­ния в файле, которым можно управлять с помощью системного вызова I seek.

Традиционно специальные файлы помещаются в каталог /dev. При появлении ново­го устройства и соответственно нового драйвера администратор системы может создать новую запись с помощью команды mknod. Например, следующая команда создает блок-ориентированный специальный файл:

mk nod /dev/dsk/sc4d2s3 b 32 33

Адресная информация специального файла состоит из двух элементов:

1. major — номер драйвера и определяет выбор драйвера, обслуживающее данный специальный файл;

2. minor – номер устройства и передается драйверу в качестве параметра вызова и указывает ему на одно из нескольких однотипных устройств, которыми драйвер может управлять.

ОС UNIX использует для хранения информации об установленных аппаратных драйверах две системные таблицы:

1. bdevsw — таблица блок-ориентированных драйверов;

2. cdevsw — таблица байт-ориентированных драйверов.

Номер драйвера (major) является индексом соответствующей таблицы. При открытии специального файла операционная система обнаруживает, что она имеет дело со специальным файлом только после того, как прочитает с диска или найдет в системном буфере его индексный дескриптор. При этом она узнает, явля­ется ли вызываемый драйвер блок- или байт-ориентированным, после чего ис­пользует номер драйвера для обращения к определенной строке одной из двух таблиц: bdevsw или cdevsw, что показано на рисунке 2.11.

Рисунок 2.11 – Организация связи ядра UNIX с драйверами.

Концепция специальных файлов ОС UNIX была реализована во многих ОС.

Драйверы и интерфейсы устройств

Достоинством подсистемы ввода-вывода любой ОС является наличие разнообразного набора драйверов для наиболее популярных периферийных устройств.

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

Драйвер взаимодействует, с одной стороны, с модулями ядра ОС, а с другой стороны — с контроллера­ми внешних устройств. Поэтому существуют два типа интерфейсов:

1. интерфейс «драйвер-ядро» (Driver Kernel Interface, DKI) должен быть стандар­тизован в любом случае;

2. интерфейс «драйвер-устройство» (Driver Device Interface, DDI)., имеет смысл стан­дартизировать тогда, когда подсистема ввода-вывода выполняет операции взаимодействия с аппаратурой контроллера самостоятельно. Подсистема ввода-вывода может поддерживать несколь­ко различных типов интерфейсов DKI/DDI, предоставляя специфический ин­терфейс для устройств определенного класса. Так, в ОС Windows NT для драй­веров сетевых адаптеров существует интерфейс стандарта NDIS (Network Driver Interface Specification), в то время как драйверы сетевых транспортных протоко­лов взаимодействуют с верхними слоями сетевого программного обеспечения по интерфейсу TDI (Transport Driver Interface).

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

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

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

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

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

На практике используют от двух до пяти ровней драйверов.

Высокоуровневые драйверы, как правило, не вызыва­ются по прерываниям, так как взаимодействуют с управляемым устройством че­рез посредничество аппаратных драйверов.

В унификацию драйверов большой вклад внесла ОС UNIX, где драйверы разделены на два больших класса

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

2. байт-ориентированные (character- oriented). Работают с не адресуемыми устройствами, они генерируют или потребляют последовательности байт (служат терминалы, строч­ные принтеры, сетевые адаптеры). Только для этого разработана среда STREAMS.

Такое деление очень полезно для структурирования подсистемы управления вводом-выводом.

Буферизация

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

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

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

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

Существуют два способа организации дискового кэша:

1. традиционный. Основан на автономном диспетчере кэша, обслу­живающем набор буферов системной памяти и самостоятельно организующим загрузку блока диска в буфер при необходимости, не обращаясь за помощью к другим подсистемам ОС. По такому принципу был организован дисковый кэш во многих ранних версиях UNIX, а также в ОС семейства NetWare;

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