Операционные системы (машбук)

Рис. 146.RAID 5. Распределенная четность (циклическое распределение четности).

Рис. 147.RAID 6. Двойная избыточность (циклическое распределение четности с использованием двух схем контроля; требуется N+2 диска).

6.2Работа с внешними устройствами в ОС Unix

6.2.1 Файлы устройств, драйверы

Как уже неоднократно упоминалось, одной из основных особенностей ОС Unix является концепция файлов: практически все, с чем работает система, представляется в виде файлов. Внешние устройства не являются исключением и также представлены в системе в виде специальных файлов устройств, хранимых обычно в каталоге /dev.

С точки зрения интерфейсов организации работы с внешними устройствами система делит абсолютно все устройства на две категории: байт-ориентированные и блок-ориентированные

устройства. С блок-ориентированными устройствами обмен осуществляется порциями данных фиксированной длины, называемыми блоками. Обычно размер блока кратен степени двойки, а зачастую кратен 512 байтам. Все остальные устройства относятся к байт-ориентированным. Такие устройства позволяют осуществлять обмен порциями данных произвольного размера (от 1 байта до некоторого k). Надо отметить, что к байт-ориентированным устройствам помимо физических

Примечание [R37]: Лекция 21 от

01.12.05.

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

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

Рассмотрим системную организацию информации, необходимой для управления внешними устройствами. Как упоминалось выше, в системе имеется специальный каталог устройств, в котором располагаются файлы особого типа — специальные файлы устройств. Эти файлы обеспечивают решение следующих задач:

именование устройств (если быть более точными, то именование драйвера устройства);

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

врабочем пространстве файловой системы. Вся содержательная информация файлов данного типа размещается исключительно в соответствующем индексном дескрипторе. Индексный дескриптор состоит из перечня стандартных атрибутов файла, среди которых, в частности, указывается тип этого файла, а также включает в себя некоторые специальные атрибуты. Эти атрибуты содержат следующие поля: тип файла устройства (блокили байт-ориентированное), а также еще 2 поля, позволяющие осуществлять работу с конкретным драйвером устройства, — это т.н. старший номер и младший номер. Старший номер (major number) — это номер драйвера в соответствующей типу файла устройства таблице драйверов. А младший номер (minor number) — это некоторая дополнительная информация, передаваемая драйверу при обращении. За счет этого реализуется механизм, когда один драйвер может управлять несколькими сходными устройствами.

6.2.2Системные таблицы драйверов устройств

Для регистрации драйверов в системе используются две системные таблицы: таблицы блокориентированных устройств — bdevsw, и таблица байт-ориентированных устройств — cdevsw. Соответственно, старший номер хранит ссылку на драйвер, хранящийся в одной из таблиц; тип таблицы определяется типом файла устройств.

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

Стоит отметить следующие типовые имена точек входа в драйвер:

βopen(), βclose();

βread(), βwrite();

βioctl();

βintr().

Символ β является аббревиатурой имени устройства: обычно в Unix-системах для именования устройства используют двухсимвольные имена. Например, lp — принтер, mt — магнитная лента, и т.п.

Примечание [R38]: Удалил

βstrategy(), т.к. ничего не говорилось по ней.

В общем случае система специфицирует наиболее полный набор функций, который может предоставить драйвер пользователю. Если какая-либо функция отсутствует, то на ее месте в коммутаторе может стоять заглушка. Заглушки могут быть двух типов: заглушка типа nulldev(), которая при обращении сразу возвращает управление, и заглушка типа nodev(), которая при обращении возвращает управление с кодом ошибки. Например, для таймера скорее всего будут отсутствовать функции чтения и записи, причем при попытке чтения или записи система должна «ругнуться» (т.е. заглушка типа nodev()).

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

Традиционно часть функций драйверов может быть реализовано синхронным способом, а другая часть — асинхронным способом. Соответственно, синхронная часть драйвера называется top half, а асинхронная — bottom half.

6.2.3 Ситуации, вызывающие обращение к функциям драйвера

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

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

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

И, в-четвертых, это выполнение специальных команд управления устройством. Функции управления могут быть самыми разными, их наполнение зависит от конкретного устройства и от конкретного драйвера.

6.2.4 Включение, удаление драйверов из системы

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

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

Примечание [R39]: Это определения взято из Робачевского.

ТОФ2

name

Рис. 148.Организация обмена данными с файлами.

Пускай в системе позже был запущен Процесс2, который также открыл файл name. В этом случае в ТФ заводится новая запись, в которой устанавливается свой указатель чтения/записи, но эта запись ТФ будет ссылаться на тот же номер записи в ТИДОФ. Такой механизм позволяет корректно (с системной точки зрения) обрабатывать ситуации одновременной работы с одним и тем же файлом: поскольку в итоге все сводится к единственной актуальной копии индексного дескриптора в ТИДОФ, то работа ведется с соответствующими блоками файла. При этом данные процессы работают с файлом каждый «по-своему», т.к. каждый из них оперирует независимыми указателями чтения/записи, хранимыми в различных записях ТФ.

Теперь предположим, что после открытия файла name, Процесс1 обращается к системному вызову fork() и порождает своего потомка — Процесс3. При обращении к системному вызову fork() ТОФ родительского процесса копируется в ТОФ сыновнего процесса. Соответственно, все записи ТОФ3 будут ссылаться на те же записи ТФ, что и записи ТОФ1. Это означает, что при порождении сыновнего процесса в соответствующих записях ТФ происходит увеличение на 1 счетчика кратности. Заметим, что подобный механизм наследования подразумевает, что дочерний процесс будет работать с теми же указателями чтения/записи, что и родительский процесс.

Рассмотренная модель организации обмена данными с файлами имеет свои достоинства и недостатки. Так, ТИДОФ располагается в оперативной памяти. Это означает, что становится эффективнее работа с файловой системой, поскольку уменьшается число обращений к пространству индексных дескрипторов файловой системы, т.е. этот механизм можно считать кэшированием системных обменов. Но эта модель имеет главный недостаток, связанный с некорректным завершением работы операционной системы: если в системе происходит сбой, то содержимое ТИДОФ будет потеряно, а это означает, что будут потери и в файловой системе.

6.2.6 Буферизация при блок-ориентированном обмене

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

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

1.Поиск заданного блока в буферном пуле. Если удачно, то переход на п.4

2.Поиск буфера в буферном пуле для чтения и размещения заданного блока.

3.Чтение блока в найденный буфер.

4.Изменение счетчика времени во всех буферах.

Примечание [R40]: В устной лекции был отвлеченный пример:

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

И т.д. я его решил опустить здесь.