Лекции Системное ПО. Лекция Структура и основные компоненты вычислительной системы
 Скачать 0.71 Mb.
|
|
Лекция 10 Говоря о двойной буферизации, следует сказать и о многоуровневой буферизации — когда ВЗУ само обладает некоторой оперативной памятью с помощью которой обеспечивает еще один уровень буферов. При многоуровневой буферизации реальный обмен и мнимый происходят с некоторой задержкой, это может плохо сказаться на функционировании процессов. Следует отметить, что Unix максимально экономит число обращений к внешним устройствам: суперблок, индексные дескрипторы — считываются в память и дальнейшая работа уже идет с ними; буферизация обменов, многоуровневая буферизация; Продолжим рассматривать файловую систему Unix Атрибуты файлов Мы говорили об организации пользователей системы, она имеет иерархическую трехуровневую структуру Любой пользователь, присутствующий в системе, принадлежит некоторой группе. В соответствии с иерархией пользователей определена иерархия защиты файлов. Определено понятие владельца файла. Изначально владельцем файла является пользователь (процесс пользователя), который создал этот файл. Атрибут “владелец файла” может быть изменен командой “chown”. Каждый файл имеет атрибуты защиты, причем они также иерархичны: права на чтение/запись/исполнение (RWX) владельца файла; права группы (для всех пользователей, кроме владельца); права всех пользователей (за исключением группы владельца и самого владельца); Изменение прав доступа можно осуществить с помощью команды “chmod”. Кроме атрибутов доступа каждый файл может иметь некоторые признаки, так называемые: t-bit: так как открытие файла — действие долгое, то для оптимизации этой процедуры введен этот атрибут, которым помечаются исполняемые файлы. Тогда при первом вызове файла за сеанс работы системы происходит копирование тела файла в область сохранения. При каждом повторном вызове файла сначала происходит просмотр области сохранения, если файл там есть, то он забирается оттуда, а в области сохранения накладных расходов на открытие файлов нет. T-bit устанавливается системным администратором, обычно это делается для наиболее часто запускаемых процессов. s-bit: все средства системы кому-то принадлежат, так как представляются в виде файлов, поэтому у каждой самой простой команды имеется владелец файла. Соответственно, каждая из этих команд может обращаться за чтением или записью в системные файлы. И возникает проблема — с одной стороны должна быть защита от несанкционированного доступа к файлу, а с другой стороны какие-то файлы должны быть доступны всем командам. Такие файлы помечаются s-bit’ом, суть его в следующем: владелец файла с s-bit’ом остается неизменным, но при запуске владельцу запустившего процесса предоставляются права по доступу к данным, как у владельца файла с s-bit’ом. Поясним на примере: Предположим, имеется исполняемый файл “file”, он каким-то образом работает с файлом “file2”, в котором находится конфиденциальная (недоступная всем) информация, предположим, “file” корректирует “file2”, где хранится, например, информация обо всех пользователях. И, в частности, он может менять пароль пользователя в системе. Если мы запустим “file” от имени пользователя “mash”, то доступ к “file2” будет заблокирован, так как “mash” не имеет права доступа к этому файлу. В противном случае, “file2” не имел бы никакой защиты. В этом случае как раз и работает s-bit, его суть в том, что владелец “file” — пользователь “root”, предположим, что его захотел запустить пользователь “mash”, если у него файла нет s-bit’а, то владельцем файла является “root”, а владельцем процесса — “mash” и в этом случае файла, которые недоступны пользователю “mash” будут недоступны процессу. Например, при таком раскладе изменить пользователю собственный пароль будет весьма затруднительно. А s-bit позволяет продлить права владельца файла на права владельца процесса. И на время работы с этим файлом процесс будет иметь все нужные права доступа. Но надо отметить, что, рассматривая наш пример, доступ к “file2” может быть осуществлен только через “file”. Напрямую “mash” по-прежнему ничего не сможет сделать. Для установки s- и t-bit’а также существует определенная команда системы. Итак, мы разобрались с доступом к конкретным файлам, а как же быть с каталогами? Как интерпретируются права доступа к каталогам? Разрешение на чтение из каталога. Это означает, что разрешен вход в каталог и открытие файлов из него; Разрешение на запись. Предоставляется возможность создавать и уничтожать файлы. Разрешение на исполнение. Возможность поиска в данном каталоге. Предположим, мы исполняем команду “ls */mash*”. Это означает, что мы ищем в текущем каталоге подкаталоги, внутри которых есть файлы, начинающиеся с “mash”. При этом выполняется поиск файлов. Это и есть тот поиск, который ассоциируется с выполнением файла-каталога. Структура файловой системы с точки зрения пользователя Сразу следует отметить, что мы будем рассматривать некоторую более общую файловую систему, потому что на сегодняшний день она может изменяться от версии к версии. Файлы “\”: “unix” — этот файл запускается программным загрузчиком и в итоге формирует ядро системы; “passwd” — все пользователи зарегистрированы в этом файле, то есть каждому пользователю соответствует строка в этом файле, которая содержит набор некоторых данных, разделенных между собой некоторым разделителем. В частности, эта строка содержит номер группы пользователя, она может содержать закодированный пароль на вход пользователя. Однако, современные unix’ы хранят пароли обычно в специальной защищенной базе данных, так как находятся умельцы, которые с помощью переборных задач (алгоритм кодирования паролей известен) подбирают пароли. Далее, строка содержит ФИО пользователя, его статус, домашний каталог (каталог, который устанавливается при входе пользователя), тип интерпретатора команд, с которым будет работать пользователь. “rc” — в этом файле в текстовом виде находится набор команд, которые будут выполнены при загрузке ОС. И так далее... Следует заметить, что Unix подавляющее большинство своей системной информации содержит в обыкновенных текстовых файлах. Это позволяет легко изменять многие параметры ОС без использования специальных средств. В этом же каталоге находятся еще полезные команды, которые позволяют: изменять пароли, ремонтировать файловую систему (локальную), запускать процесс тестирования и коррекции файловой системы “fsch” и т.д. Каталоги: “etc” — содержит стандартные файлы данных системы и команды, обеспечивающие управление некоторым уровнем функционирования системы; “bin” — здесь находится подавляющее число команд, доступных пользователю, таких как: “rm”,”ls”,... “mnt” — каталог, к которому можно “примонтировать” локальные файловые системы. Мы говорили об организации файловой системы на одном внешнем устройстве, но реально для систем этого мало. Обычно требуется иметь основную файловую систему и любое число локальных, расположенных на других устройствах. Они монтируются с помощью команды “mount”. Это означает, что корень локальной файловой системы после монтирования ассоциируется с этим каталогом, и доступ к любому файлу из локальной файловой системы есть лишь указание пути от корня файловой системы до соответствующего узла через каталог “mnt”. “dev” — в этом каталоге размещаются файлы, ассоциированные с конкретными драйверами внешних устройств. К примеру, “tty01”, “tty02”, “consolp”, ... Как было сказано ранее — эти файлы не имеют содержимого, но имеют специальные поля в ИД, определяющие ссылки на таблицу драйверов и некоторую другую информацию. “usr”: “lib” — содержит библиотеки группового пользования, как то — компилятор Си, например. “bin” — каталог для размещения команд. Есть некоторые негласные правила, которые определяют — стоит положить команду в “\bin” или в “\usr\bin”. Обычно в “\bin” кладут стандартные команды. “include” — здесь лежат файлы заголовков, которые, например, используются компилятором Си, когда мы употребляем команду “include На этом мы заканчиваем рассмотрение файловой системы Unix. Подведем итог — Файловая система Unix: иерархическая; многопользовательская; имеет глубокую многоярусную буферизацию при обменах с реальными устройствами; является информационной основой функционирования самой ОС; расширяемая; с точки зрения логической организации имеет понятную и прозрачную структуру, но это накладывает определенные условия на администрацию системы, однако, это влечет за собой проблемы распределения уровней доступа к информации и размещении информации; Лекция 11 Управление процессами. Ядро системы. Мы говорили о том, что вторым по значимости понятием в ОС является понятие процесса. Процесс — вещь, которая определяется по-разному. Это может быть — “упорядоченный набор команд и принадлежащих ему ресурсов”. С точки зрения ОС Unix процесс — это объект, зарегистрированный в специальной таблице процессов. Структура этой таблицы следующая: она позиционна (как практически и все таблице в Unix), то есть номер записи в таблице — есть идентификатор процесса “PID”. Формируются процесс с 0, до N-1, где N — предельное число процессов, которые система может одновременно обрабатывать. Это параметр настройки ОС. Рассмотрим информативную нагрузку таблицы. В строке (записи) таблицы находится ссылка на контекст процесса, там же находится ссылка на тело процесса. Телом процесса мы будем называть набор команд и данных, которыми оперирует процесс. Контекст процесса — атрибут, который присутствует практически во всех ОС, в разных ОС он может называться по-разному. Контексты всех процессов размещаются в адресном пространстве ОС и содержат оперативную информацию о состоянии процесса и текущую информацию, связанную с процессом и его запуском. Контекст содержит: номера пользователя и группы; указатель на ИД текущего каталога; специфические условия работы процесса: - обработка сигналов; Рассмотрим это подробнее. В ОС Unix каждый процесс может послать другому процессу некоторое воздействие, которое называют “сигнал”, соответственно, если процесс-отправитель имеет право передать сигнал процессу-получателю, то при выполнении передачи в последнем возникает событие, связанное с сигналом. Это событие очень похоже на прерывание, возникающее в аппаратуре вычислительной системы. В ОС имеется набор сигналов, которые могут передавать процессы друг другу. Перечень сигналов описан в файле “signal.h”, отправитель может подать некоторым образом команду ОС, что он передает сигнал с заданным номером процессу-получателю, процесс-получатель может прореагировать на сигнал тремя способами: прекращение выполнения и причиной завершения является пришедший сигнал; игнорирование сигнала (здесь следует отметить, что игнорировать можно далеко не все сигналы); вызывается предопределенная процессом функция, которая может выполнить какие-то действия и возврат из этой функции есть возврат в точку прихода сигнала. - информация об открытых в процессе файлах; - информация о текущем состоянии процесса на случай его приостановки; Тогда, когда процесс остановлен, ОС “упрятывает” в соответствующий контекст информацию, нужную для его продолжения: режимы программы в момент приостановки, состояние регистров, адрес точки прерывания. Тело процесса — как уже было сказано, его можно представить в виде объединения сегмента текста (кода) и сегмента данных. Развитые ОС позволяют размещать сегменты текста и данных в различных, не зависящих друг от друга местах оперативной памяти. Это хорошо, так как вместоодного большого куска памяти нам требуется два маленьких. Но еще лучше следующее — такая организация позволяет использовать повторно входимый код. Суть его в том, что допускается существование в системе еще одного процесса с собственным контекстом, сегментом данных, но у которого общий с другими процессами сегмент текста. Если K пользователей вызывают один текстовой редактор, то в системе находится одна копия этого редактора и K копий сегмента данных и контекстов (копии, надо заметить, не идентичные). Это вещь полезная, так как отсюда сразу же можно увеличить “разум” планировщика откачки (он может, например, откачивать сегмент данных, а не сегмент текста). Мы перечислили не все содержимое контекста, и в дальнейшем эта информация будет дополняться и уточняться. Мы говорили, каким образом в Unix можно создать копию текущего процесса — это функция fork(), она работает следующим образом: fork(): >0 PID сыновнего процесса (мы находимся в процессе-отце) =0 (мы находимся в процессе-сыне) =-1 ошибка — невозможность создать новый процесс (остаемся в процессе-отце), эта ошибка может возникнуть при недостатке места в таблице процессов, при нехватке места в системных областях данных и т.п. Система поддерживает родственные взаимоотношения между процессами, это означает, что существуют некоторые функции, характерные для работы с процессами, которые доступны только процессам, являющимся родственниками. При порождении сыновнего процесса с использованием fork() порожденный процесс наследует: окружение. При формировании процесса ему передается некоторый набор параметров переменных, используя которые процесс может взаимодействовать с операционным окружением (интерпретатором команд и т.д.); файлы, открытые в процессе-отце, за исключением тех, которым было запрещено передаваться специальным параметром при открытии; способы обработки сигналов; разрешение переустановки действующего идентификатора пользователя (это то, что связано с s-bit’ом)* установленный режим отладки. В ОС имеется возможность системными вызовами осуществлять отладку (профилирование) программы, в процессе может быть указано — разрешено или нет профилирование; все присоединенные разделяемые сегменты памяти. У нас есть механизм управления разделяемыми ресурсами и в качестве одного из разделяемых ресурсов может выступать оперативная память, в ней может быть выделен сегмент, к которому одновременно имеют доступ несколько процессов. При формировании сыновнего процесса эта часть памяти также будет унаследована; текущий рабочий каталог и корневой каталог; Не наследуется при создании нового процесса идентификатор процесса (почему — очевидно). Возвращаясь к функции fork(), следует заметить, что она сама по себе бессмысленна, ибо применение такому созданию точной копии процесса найти весьма сложно. Поэтому функция fork() используется совместно с группой функций exec(...). Эта группа объединяет в себе функции, которые частью своего имени имеют слово “exec” и имеют по сути дела похожее назначение, отличающееся лишь деталями (набором или интерпретацией параметров). Суть exec в следующем: при обращении к ней происходит замена тела текущего процесса, оно заменяется в соответствии с именем исполняемого файла, указанного одним из параметров функции. Функция возвращает: -1, если действие не выполнено и код отличный от -1, если операция прошла успешно. Здесь следует отметить следующий факт — в Unix при работе с системными вызовами иногда возникают диагностические сообщения в виде кода ответа, которые невозможно разделить на конкретные причины, вызвавшие возврат этого кода. Примером этого являются коды “-1” для fork() и exec(...). Для того, чтобы обойти это неудобство, следует включить в программу файл “errno.h”, и после этого при возникновении отказов в выполнении системных вызовов в переменной “errno” будет код конкретной причины отказа выполнения заказа. Всевозможные коды отказа описаны в самом “errno.h”. Давайте приведем небольшой пример: Мы напишем программу, которая будет запускать файлы, имена которых перечислены при вызове. main(argc, argv) int argc; char **argv; { int i, pid; for (i=1; i if (pid=fork()) continue; /* отец*/ execlp(argv[i], argv[i], (char *) 0); } } Здесь, в случае, если pid=0, то мы замещаем тело процесса-сына процессом, имя файла которого нам передается в качестве параметра. Если же pid>0, то есть мы находимся в процессе-отце, то продолжаем создавать сыновьи процессы пока есть аргументы. В качестве иллюстрации работы fork() можно привести следующую картинку: Здесь процесс с PID=105 создается процессом с PID=101. Также следует отметить, что если убивается процесс-отец, то новым отцом становится 1ый процесс ОС. Связка fork-exec по своей мощности сильнее, чем если бы была единая функция, которая сразу бы создавала новый процесс и замещала бы его содержимое. А fork-exec позволяют вставить между ними вставить еще некоторую программу, которая будет содержать какие-то полезные действия. Мы начали рассматривать организацию процессов. Мы на пальцах показали, как размещается информация в ОС. В принципе, вся информация, которая отражает оперативное состояние ОС, а также программы ОС, которые управляют этой информацией, которые управляют наиболее важными устройствами составляют ядро ОС. Ядро ОС — программа, функцией которой является управления базовыми объектами системы (для Unix это два объекта — файл и процесс). Ядро в своем теле размещает необходимые таблицы данных. И вообще ядро считается некоторой неразделяемой частью ОС. Ядро обычно работает в режиме супервизора, все остальные функции ОС могут работать и в других режимах. |