Шпаргалка по "Системное програмное обеспечение"

Хотя отображение файлов исключает потребность в выполнении ввода-вывода и тем самым облегчает программирование, этот способ порождает и некоторые новые проблемы. Во-первых, для системы сложно узнать точную длину выходного файла, в данном примере ddd. Проще указать наибольший номер записанной страницы, но нет способа узнать, сколько байт в этой странице было записано. Предположим, что программа использует только страницу номер 0, и после выполнения все байты все еще установлены в значение 0 (их начальное значение). Быть может, файл состоит из 10 нулей. А может быть, он состоит из 100 нулей. Как это определить? Операционная система не может это сообщить. Все, что она может сделать, так это создать файл, длина которого равна размеру страницы.

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

Третья проблема состоит в том, что файл может быть больше, чем сегмент, и даже больше, чем все виртуальное адресное пространство. Единственный способ ее решения состоит в реализации вызова MAP таким образом, чтобы он мог отображать не весь файл, а его часть. Хотя такая работа, очевидно, менее удобна, чем отображение целого файла.

34. Организация ввода-вывода в UNIX

Мы уже обсуждали проблемы организации ввода/вывода в ОС UNIX в п. 2.6.2. В этом разделе мы хотим рассмотреть этот вопрос немного более подробно, разъяснив некоторые технические детали. При этом нужно отдавать себе отчет, что в любом случае мы остаемся на концептуальном уровне. Если вам требуется написать драйвер некоторого внешнего устройства для некоторого конкретного варианта ОС UNIX, то неизбежно придется внимательно читать документацию. Тем не менее знание общих принципов будет полезно.

Традиционно в ОС UNIX выделяются три типа организации ввода/вывода и, соответственно, три типа драйверов. Блочный ввод/вывод главным образом предназначен для работы с каталогами и обычными файлами файловой системы, которые на базовом уровне имеют блочную структуру. В пп. 2.4.5 и 3.1.2 указывалось, что на пользовательском уровне теперь возможно работать с файлами, прямо отображая их в сегменты виртуальной памяти. Эта возможность рассматривается как верхний уровень блочного ввода/вывода. На нижнем уровне блочный ввод/вывод поддерживается блочными драйверами. Блочный ввод/вывод, кроме того, поддерживается системной буферизацией (см. п. 3.3.1).

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

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

35. Файлы устройств

Файлы в директориях /dev/term и /dev/cua на самом деле являются просто синонимами (soft-links) файлов устройств последовательного порта, которые расположены в директории /devices.

Посмотрим на вывод команды ls:

# ls -lL /dev/term/* /dev/cua/*

crw-------    1 lp     sys      29,     0 Jul  6 14:31 /dev/term/a

crw--w----    1 uucp   tty      29,     1 Mar 10 12:14 /dev/term/b

crw-rw-rw-    1 root   sys      29,131072 Jul  6 14:31 /dev/cua/a

crw-rw-rw-    1 uucp   7152     29,131073 Jul 10 12:14 /dev/cua/b

                                ^^ ^^^^^^

                                |    |

Major Device Number -------------    |

Minor Device Number ------------------

Значения, которые имеют старший номер устройства (Major Device Number) и младший номер устройства (Minor Device Number) данного файла устройства определяют свойства, которыми обладает физическое устройство последовательного порта, при доступе к нему через данный файл.

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

Значение младшего номера устройства, однако, влияет на поведение устройства. На поведение устройства также влияет связка (linking) файла с физическим устройством последовательного порта.

Для файлов устройств /dev/term/N, младший номер устройства является последовательным номером, начинающимся с нуля, и этот номер ассоциирует файл устройства с физическим последовательным портом. Для файлов устройств /dev/cua/N, младший номер устройства тот-же самый, что и для /dev/term/N, за исключением того, что его наиболее значимый бит установлен в "1". Это приводит к тому, что в Solaris 2.x (SunOS 5.x) к младшему номеру устройства добавляется 131072, а в Solaris 1.x (SunOS 4.x) добавляется 128. Причиной различия является тот факт, что длина структуры, которая представляет младший номер устройства в Solaris 2 больше, чем в Solaris 1.

В вышеприведённом выводе команды ls на системе Solaris 2.x, видно, что устройство /dev/term/b имеет старший/младший номера 29 и 1, и теперь мы уже знаем, что соответствующий файл устройства /dev/cua/b будет иметь старший номер 29 и младший номер 1 + 131072 = 131073.

36. Монтирование файловых систем

1. Использование меню OA&M для монтирования файловой системы

2. Использование mount для монтирования файловой системы

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

Это выполняется путем "монтирования" файловой системы. При этом используются меню OA&M или команда mount (1M). Этот этап обязателен.

Выполнение команды mount требует попарного соединения смонтированного дискового устройства и вмонтированного каталога. Система UNIX обеспечивается информацией о типе файловой системы, о параметрах, используемых для монтирования и о времени, необходимом для монтажа. Эта информация хранится в файле /etc/mnttab.

Например, команда

              mount -F s5 /dev/dsk/1s2/usr

просит систему смонтировать /dev/dsk/1s2 как s5 файловую систему, которая начинается в каталоге /usr.

Если вы попытаетесь заменить каталоги (при помощи команды cd) на каталог в файловой системе usr до выхода команды mount, то команда cd не выполнится. Пока не завершится команда mount, система не будет знать ни о каких каталогах в файловой системе usr.

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

Команда labelit также помогает осуществить связь между специальным файлом устройства и смонтированным именем файловой системы. Она записывает каталог наивысшего уровня файловой системы (т.е. ее имя) в поле в системном блоке тома.

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

37. Сигналы в UNIX

Сигналы в UNIX, Unix-подобных и других POSIX-совместимых операционных системах являются одним из способов взаимодействия между процессами (англ. IPC, inter-process communication). Фактически, сигнал — это асинхронное уведомление процесса о каком-либо событии. Когда сигнал послан процессу, операционная система прерывает выполнение процесса. Если процесс установил собственный обработчик сигнала, операционная система запускает этот обработчик, передав ему информацию о сигнале. Если процесс не установил обработчик, то выполняется обработчик по умолчанию.

Названия сигналов «SIG…» являются числовыми константами (макроопределениями Си) со значениями, определяемыми в заголовочном файле signal.h. Числовые значения сигналов могут меняться от системы к системе, хотя основная их часть имеет в разных системах одни и те же значения. Утилита kill позволяет задавать сигнал как числом, так и символьным обозначением.

Содержание

1 Посылка сигналов

2 Обработка сигналов

3 Безопасность

4 Классификация сигналов

5 SA_SIGINFO

6 См. также

7 Ссылки

Посылка сигналов

Сигналы посылаются:

с терминала, нажатием специальных клавиш или комбинаций (например, нажатие Ctrl-C генерирует SIGINT, а Ctrl-Z SIGTSTP);

ядром системы:

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

ошибочных системных вызовах;

для информирования о событиях ввода-вывода;

одним процессом другому (или самому себе), с помощью системного вызова kill(), в том числе:

из шелла, утилитой /bin/kill.

Сигналы не могут быть посланы завершившемуся процессу, находящемуся в состоянии «зомби».

Обработка сигналов

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

Безопасность

Процесс (или пользователь из шелла) с эффективным UID, не равным 0 (UID суперпользователя), может посылать сигналы только процессам с тем же UID.

38. Понятие о надежности сигналов

Основным недостатком системного вызова signal() является его низкая надежность.

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

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

Наконец, последний недостаток связан с невозможностью определить сколько сигналов одного и того же типа поступило процессу пока он находился в состоянии готовность. Сигналы одного типа не ставятся в очередь! Процесс может узнать о том, что сигнал или сигналы определенного типа были ему переданы, но не может определить их количество. Эту черту мы можем проиллюстрировать, слегка изменив программу с асинхронным получением информации о статусе завершившихся процессов, рассмотренную нами ранее. Пусть в новой программе процесс-родитель порождает в цикле пять новых процессов, каждый из которых сразу же завершается со своим собственным кодом, после чего уходит в бесконечный цикл (файл /fnp/pub/sem/sem13-14/stud/s13-7.c). Сколько сообщений о статусе завершившихся детей мы ожидаем получить? Пять! А сколько получим? It depends... Откомпилируйте, прогоните и посчитайте.

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

Рассмотрение POSIX сигналов выходит за рамки нашего курса. Желающие могут самостоятельно посмотреть описания функций и системных вызовов sigemptyset(), sigfillset(), sigaddset(), sigdelset(), sigismember(), sigaction(), sigprocmask(), sigpending(), sigsuspend() в UNIX Manual.