ОС семейства UNIX. Управление вводом-выводом. Блочные, символьные и потоковые драйверы.

Управление вводом – выводом. Традиционно в ОС UNIX выделяются три типа организации ввода/вывода и, соответственно, три типа драйверов.

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

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

Наконец, потоковый ввод/вывод похож на символьный ввод/вывод, но по причине

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

Принципы системной буферизации ввода/вывода.

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

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

В System V Release 4 появилась новая схема буферизации, пока используемая параллельно со старой схемой. Суть новой схемы состоит в том, что на уровне ядра фактически воспроизводится механизм отображения файлов в сегменты виртуальной памяти. Во-первых, напомним о том, что ядро ОС UNIX действительно работает в собственной виртуальной памяти. Эта память имеет более сложную, но принципиально такую же структуру, что и пользовательская виртуальная память. Другими словами, виртуальная память ядра является сегментно-страничной, и наравне с виртуальной памятью пользовательских процессов поддерживается общей подсистемой управления виртуальной памятью. Из этого следует, во-вторых, что практически любая функция, обеспечиваемая ядром для пользователей, может быть обеспечена одними компонентами ядра для других его компонентов. В частности, это относится и к возможностям отображения файлов в сегменты виртуальной памяти.

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

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

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

Системные вызовы для управления вводом/выводом

Для доступа (т.е. для получения возможности последующего выполнения операций ввода/вывода) к файлу любого вида (включая специальные файлы) пользовательский процесс должен выполнить предварительное подключение к файлу с помощью одного из системных вызовов open, creat, dup или pipe.

Последовательность действий системного вызова open (pathname, mode) следующая:

· анализируется непротиворечивость входных параметров (главным образом, относящихся к флагам режима доступа к файлу);

· выделяется или находится пространство для описателя файла в системной области данных процесса (u-области);

· в общесистемной области выделяется или находится существующее пространство для размещения системного описателя файла (структуры file);

· производится поиск в каталоге файловой системы объекта с именем "pathname" и образуется или обнаруживается описатель файла уровня файловой системы (vnode в терминах UNIX V System 4);

· выполняется связывание vnode с ранее образованной структурой file.

Системные вызовы open и creat (почти) функционально эквивалентны. Любой существующий файл можно открыть с помощью системного вызова creat, и любой новый файл можно создать с помощью системного вызова open. Однако, применительно к системному вызову creat мы должны подчеркнуть, что в случае своего естественного применения (для создания файла) этот системный вызов создает новый элемент соответствующего каталога (в соответствии с заданным значением pathname), а также создает и соответствующим образом инициализирует новый i-узел.

Наконец, системный вызов dup (duplicate - скопировать) приводит к образованию нового дескриптора уже открытого файла. Этот специфический для ОС UNIX системный вызов служит исключительно для целей перенаправления ввода/вывода. Его выполнение состоит в том, что в u-области системного пространства пользовательского процесса образуется новый описатель открытого файла, содержащий вновь образованный дескриптор файла (целое число), но ссылающийся на уже существующую общесистемную структуру file и содержащий те же самые признаки и флаги, которые соответствуют открытому файлу-образцу.

Другими важными системными вызовами являются системные вызовы read и write. Системный вызов read выполняется следующим образом:

· в общесистемной таблице файлов находится дескриптор указанного файла, и определяется, законно ли обращение от данного процесса к данному файлу в указанном режиме;

· на некоторое (короткое) время устанавливается синхронизационная блокировка на vnode данного файла (содержимое описателя не должно изменяться в критические моменты операции чтения);

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

Операция записи выполняется аналогичным образом, но меняет содержимое буфера буферного пула.

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

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

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

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

4.1. Сравнительные особенности ядер операционных систем Windows NT и OS/2

Ядро Windows NT

"Сердцем" операционной системы Windows NT, работающим в тесной взаимосвязи с HAL, является ядро (или микроядро - microkernel). Ядро осуществляет диспетчеризацию нитей, обработку прерываний и исключительных ситуаций. Если компьютер имеет многопроцессорную архитектуру, ядро повышает производительность системы, синхронизируя работу процессоров. В

мультипроцессорной конфигурации ядро может одновременно выполняться на всех процессорах. Роль ядра заключается в том, чтобы обеспечить оптимальную загрузку всех процессоров и наилучшую производительность системы. Для этого ядро осуществляет диспетчеризацию нитей в соответствии с их приоритетами. Фактически, оно принудительным образом проводит политику диспетчеризации, реализуемую модулем Windows NT Executive. Кроме того, ядро вытесняет (preempt) нити с низким приоритетом в пользу более высокоприоритетных нитей. Оно может принудительным образом выполнять переключения контекста (context switches), давая процессору инструкции прекратить выполнение одной задачи и взяться за другую. Таким образом, код, выполняющийся в такой системе, должен быть реентерабельным (reentrant). Под реентерабельностью кода понимается способность прервать выполнение и быть выгруженным, а также возобновить выполнение без потери информации. Кроме того, реентерабельный код может совместно использоваться несколькими различными нитями, выполняющими различные строки одного и того же кода на различных процессорах.

Ядро является единственной неперемещаемой в памяти (nonpageable) и невыгружаемой (nonpreemptible) частью операционной системы. За редким исключением все остальные нити, работающие в Windows NT 4.0, в том числе и в составе модуля Executive, являются выгружаемыми (preemptible) и полностью реентерабельными. За счет этого достигается максимальная эффективность системы. Наконец, ядро синхронизирует деятельность таких сервисов Windows NT Executive, как Диспетчер ввода/вывода (I/O Manager) и Диспетчер процессов (Process Manager). Кроме того, компоненты Executive используют еще более высокие уровни абстракции, называемые объектами микроядра (microkernel objects), часть из которых экспортируется в пределах интерфейсных вызовов API с пользовательскими приложениями.

Ядро OS/2

Не нашли, что искали? Воспользуйтесь поиском: