ГОСЫ / Bilety

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

Перенаправление ввода/вывода

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

Реализация механизма основывается на следующих свойствах ОС UNIX. Во-первых, любой ввод/вывод трактуется как ввод из некоторого файла и вывод в некоторый файл. Клавиатура и экран терминала тоже интерпретируются как файлы (первый можно только читать, а во второй можно только писать). Во-вторых, доступ к любому файлу производится через его дескриптор (положительное целое число). Фиксируются три значения дескрипторов файлов. Файл с дескриптором 1 называется файлом стандартного ввода (stdin), файл с дескриптором 2 – файлом стандартного вывода (stdout), и файл с дескриптором 3 – файлом стандартного вывода диагностических сообщений (stderr). В-третьих, программа, запущенная в некотором процессе, “наследует” от породившего процесса все дескрипторы открытых файлов.

В головном процессе интерпретатора командного языка файлом стандартного ввода является клавиатура терминала пользователя, а файлами стандартного вывода и вывода диагностических сообщений – экран терминала. Однако при запуске любой команды можно сообщить интерпретатору (средствами соответствующего командного языка), какой файл или вывод какой программы должен служить файлом стандартного ввода для запускаемой программы и какой файл или ввод какой программы должен служить файлом стандартного вывода или вывода диагностических сообщений для запускаемой программы. Тогда интерпретатор перед выполнением системного вызова exec открывает указанные файлы, подменяя смысл дескрипторов 1, 2 и 3.

Конечно, то же самое может проделать и любая другая программа, запускающая третью программу в специально созданном процессе. Следовательно, все, что требуется для нормального функционирования механизма перенаправления ввода/вывода – это придерживаться при программировании соглашения об использовании дескрипторов stdin, stdout и stderr. Это не очень трудно, поскольку в наиболее распространенных функциях библиотеки ввода/вывода printf, scanf и error вообще не требуется указывать дескриптор файла. Функция printf неявно использует stdout,

функция scanf – stdin, а функция error – stderr.

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

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

31

2. Информационное наполнение UNIX. Описание организации информационной подсистемы UNIX. Структура руководств (manpages) и подсистемы info. Алгоритм поиска информации.

Руководство

Аккуратная документация - непременная составная часть проективной системы. Чтобы по всякому поводу не приниматься изучать систему целиком, надо предусмотреть средство ограничения контекста, позволяющее выбирать документацию по теме. Выходит, что документацией по какойнибудь утилите не могут служить, скажем, технические замечания, Changelog (он же Whatsnew) и даже README, включаемые в исходные тексты данной утилиты. Это, условно говоря, документация для программистов (точнее - для тех, кто будет улучшать или исправлять саму утилиту). Нас же интересует документация для пользователей (т. е. для тех, кому утилита понадобится в работе). К тому же описание утилиты (Утилита — вспомогательная компьютерная программа в составе общего программного обеспечения для выполнения специализированных типовых задач, связанных с работой оборудования и операционной системы (ОС)) и способов ее применения должно быть дополнено некоторой задающей контекст информацией: для чего утилита, чем она пользуется, что еще стоит почитать. Если речь идет о внушительных размеров пользовательском прикладном пакете, которым не пользуются другие части системы, стоит рассматривать сам этот пакет как систему, внутри которой опять-таки требуется ограничивать контекст, дабы не изучать ее целиком (так устроена, например, документация по Tcl/Tk).

Исторически первая, главная и наиболее сбалансированная система документации в UNIX называется "страницы руководства" (manual pages), или, для краткости "руководства" (manuals). Страницы руководства появились уже в первой версии UNIX: не все писали утилиту, но все хотят ею пользоваться (а вначале появлялись самые нужные), и тут без документации - никуда. А поскольку некая система документирования в то время уже существовала (см. 5), ее и взяли за основу. На примере того, как организованы страницы руководства, хорошо видно, как формировались принципы построения системы, из чего они произрастали и как они работают сейчас, со всеми их достоинствами и недостатками.

Средством просмотра страниц руководства служит утилита man. Самый простой способ ею воспользоваться - написать что-нибудь в командной строке man. Например, команда man man выдаст руководство по самой этой утилите, которое можно просмотреть постранично, перелистывая страницы клавишей "пробел". Руководства есть не только у каждой утилиты системы, но и у многих других объектов. Все страницы руководства отнесены к восьми разделам:

1.пользовательские утилиты и прочие инструменты;

2.системные вызовы;

3.библиотечные вызовы (функции);

4.внешние устройства (и их представление в системе);

5.форматы и таблицы (типы файлов, протоколы и пр.);

6.игры и всевозможные "ненужные" утилиты (например, fortune);

7.прочее, т. е. то, что не подходит под другие разделы;

8.команды и инструменты системного администратора.

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

Поля руководства

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

Краткое описание

32

Семантическое

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

Синтаксическое

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

Описание

Поле DESCRIPTION содержит развернутое описание объекта. Сюда попадает любая разъяснительная информация: принципы работы данной утилиты или функции, назначение и общая структура данного системного файла, описание внешних устройств, соответствующих данному драйверу и т. п. Поле может быть довольно большим: информации в нем должно быть достаточно для понимания устройства и работы объекта. Если утилита сама по себе сложна и описание принципов ее работы в DESCRIPTION довольно пространно, перечень возможных параметров командной строки (иными словами, ключей) с подробным изложением того, как и зачем их применять, выносят в поле OPTIONS. Если работа инструмента зависит от каких-либо переменных окружения (см. лекцию 17), их список помещается в поле ENVIRONMENT.

Результат

Функция или системный вызов, как правило, возвращают какое-нибудь значение. По окончании работы утилиты вырабатывается так называемый код возврата (или код ошибки, который не равен нулю в случае неудачного завершения работы). Наконец, функция или системный вызов могут завершиться с разными видами ошибок. Для описания результатов работы в руководствах имеются поля RETURN VALUES, DIAGNOSTICS и ERRORS соответственно.

Использование

Иногда использование объекта невозможно или некоторый, на первый взгляд очевидный путь его применения приводит к неочевидным последствиям. Тогда стоит поместить примеры такого рода ситуаций в поле CAVEATS. Небольшие примеры успешного использования объекта с описанием решаемой в них задачи приводятся в поле EXAMPLES, а типичные ошибки при работе с объектом, равно как и недочеты в его реализации, - в поле BUGS.

Ссылки на другие объекты

Если утилита работает с какими-нибудь файлами, использует или изменяет их, эти файлы перечисляются в поле FILES, даже если на них нет руководства. Поработав с некоторым инструментом системы, пользователь может просмотреть все файлы из поля FILES руководства, и узнать, откуда этот инструмент взял дополнительные данные и что изменил. Одно из самых важных - поле SEE ALSO. В него включаются ссылки на те источники информации, которые автор руководства считает относящимися к теме: на книги, включенные в систему учебники и статьи и - главное - на другие страницы руководства. Кроме того, в тексте всего руководства непременно встретятся ссылки на другие объекты, по которым тоже есть руководства. В этом случае, как и в поле SEE ALSO, после имени объекта в скобках указывается номер раздела, в котором стоит искать руководство.

Родословная

33

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

Особенности руководств

Бывают объекты с одинаковыми именами, но принадлежащие разным разделам, например утилита passwd, позволяющая пользователю менять пароль, и файл passwd, в котором хранится учетная запись пользователя (по иронии судьбы в современных версиях UNIX именно пароля там и нет). Для того чтобы посмотреть руководство по passwd из пятого раздела, надо использовать команду man 5 passwd, а если вам неизвестно, к какому разделу относится объект, - man -a passwd (тогда вы увидите руководства по всем объектам с именем passwd). При ссылке на страницу руководства принято после имени объекта указывать в круглых скобках номер раздела passwd(1) и passwd(5).

В каждом разделе существует специальный объект intro, руководство по которому описывает назначение раздела и определяет основные термины. Кроме того, в поле SEE ALSO этих руководств помещаются ссылки на страницы руководства по крупным темам (например, security(7)).

Цель же руководства - сообщить все, что известно об объекте (например, поточном текстовом редакторе sed), и указать на то, что существует некий предмет рассмотрения, с которым этот объект связан (автоматическая обработка текстов). Причем указание это делается не напрямую, а путем ссылок на иные объекты, тоже относящиеся к делу. Руководство - это справочник; его читают, когда имеют представление о том, что делать, но не знают в точности - как.

Смысловая структура системы руководств

Первое, что бросается в глаза, - это ее совершенно естественное происхождение. Устройство подсистемы руководств носит следы и основ эргономики (правило "7±2", [32]), и принципов построения компьютерных систем, а также очевидной гипертекстовой структуры: в страницах руководства есть несколько видов гипертекстовых ссылок. Никаких механизмов перехода по ссылкам в manpages не предусмотрено: предполагается, что, во-первых, сначала лучше дочитать открытое руководство, а во-вторых, если потребуется, всегда можно запустить команду man на соседнем терминальном устройстве (виртуальной консоли или X-терминале). К тому же технически переход по некоторым видам ссылок реализовать не так просто, как это предлагают, скажем, средства просмотра HTML, где используются только контекстные гиперссылки.

Контекстными называются те ссылки, что встречаются внутри текста. Если упоминаемый в руководстве объект имеет собственное руководство, пользователю, возможно, стоит прочесть и его. Для этого, как уже было сказано, после имени объекта ставится в круглых скобках номер раздела, в котором хранится его руководство. Контекстные ссылки не выделяются из текста и почти не мешают чтению, однако именно они задают сеть, связывающую все объекты системы. Расставлять контекстные ссылки надо с осторожностью. Не каждое встреченное имя документированного объекта должно ссылаться на его документацию. Лучше всего превращать объект в контекстную ссылку, только когда читателю действительно может понадобиться соответствующее руководство: при первом упоминании объекта и в тех случаях, когда объект упоминается после продолжительного перерыва или в какой-нибудь иной ипостаси.

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

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

34

ему не свойственное: например, ответ на типовой вопрос. Из типовых вопросов и ответов обычно составляется документ под названием FAQ (frequently asked questions, или часто задаваемые вопросы, ЧаВо), а специфике руководства это не соответствует. Поэтому где-нибудь в поле SEE ALSO должна находиться внешняя ссылка на подобный документ.

Летописными ссылками мы будем называть всякое упоминание не относящихся к предмету рассмотрения объектов: историю создания утилиты, авторов, www-страницу и пр., что встречается чаще всего в полях AUTHORS, HISTORY, AVAILABILITY и т. п. Эти ссылки либо вообще приводятся для удовлетворения любопытства пользователей, либо просто косвенно дополняют описание.

Утилита man

Утилита man(1) - составная, ее вызов - это последовательное выполнение трех операций: поиск страницы руководства, форматирование найденной страницы и просмотр отформатированного текста.

Сами страницы помощи - это файлы, имена которых включают имена объектов. Файлы расположены в некотором базовом каталоге (например, в /usr/share/man или в /usr/X11R6/share/man) в подкаталогах man1, man2 и т. д. по количеству разделов. Таким образом, первая стадия работы утилиты man сводится к поиску первой страницы с именем объекта во всех секциях базовых каталогов. Кстати, именно поэтому секция, посвященная администрированию, сделана восьмой: если пользователь вызовет man без указания раздела, то при совпадении имен объектов он получит руководство по утилите, а системному администратору ничего не стоит написать в командной строке man 8.

Третья стадия работы man - вызов утилиты постраничного просмотра текста more(1). Подобие more, лишенное всех функций, кроме главной, можно найти даже в DOS. Во многих современных системах вместо more используется более мощная утилита less(1). Говорят: "Less is more than more". Утилита позволяет просматривать простой текст и текст, выходящий из-под nroff, при этом используются возможности терминала: "двойной удар" превращается в текст повышенной яркости, а подчеркивание - в подчеркнутый. (В системе Solaris man почему-то вызывает more с ключом, запрещающим обрабатывать подчеркнутый текст, отчего внешний вид руководства ухудшается.) Исходные тексты утилиты more в Solaris недоступны, и приходится подменять ее командным сценарием, в котором параметры командной строки передаются настоящей утилите more уже поправленными. Если вы хотите вывести руководство на печать, причем не на АЦПУ, а на современный PostScript-принтер, лучше не обрабатывать выдачу man, а воспользоваться предназначенной для этого утилитой troff(1). Получившаяся командная строка может быть, например, такой:

zcat /usr/share/man/man1/man.1.gz | troff -man -Tps | grops | lpr

Для каждой из этих утилит есть руководство, а о том, что такое "|" ("конвейер"), рассказано в лекции 11.

Утилиты whatis и apropos

Самая краткая часть страницы руководства - однострочное поле NAME - тоже играет очень важную роль в системе информационной поддержки. Дело в том, что при установке руководства в систему содержимое этого поля добавляется в файл whatis, лежащий в базовом каталоге. Текстовый файл whatis - оглавление всей системы руководств, находящейся в соответствующем каталоге. Если поискать некоторое слово в этом файле, мы увидим только те заголовки руководств, в которых оно встречается. Поиском ключевых слов в whatis занимаются утилита whatis(1) и apropos(1), которая ищет не целое слово, а просто подстроку в строке.

Работа с руководствами

Допустим, мы хотим слить два файла, left и right, в один, состоящий из двух колонок (содержимое одного файла - слева, другого - справа). Спрашиваем, в описании каких утилит есть слово column:

$ apropos column

35

...

Команда apropos выдает несколько сотен строк относящихся в основном, к графическим функциям (секция 3). Нас же интересует утилита (секция 1). Используем grep(1), чтобы выбрать только строки, содержащие (1) (поле NAME начинается с контекстной ссылки на само руководство).

$ apropos column | grep "(1)"

colrm(1)	- remove columns from a file
column(1)	- columnate lists

Другое дело! Наверное, нам нужна утилита column? Читаем руководство. $ man column

...

Не тут-то было... Смотрим поле SEE ALSO

$ man column | colcrt | sed -n '/SEE ALSO/,/^$/p' SEE ALSO

colrm(1), ls(1), paste(1), sort(1)

(В примере за нас все сделал UNIX. Как именно? Читайте руководство по colcrt и главу 14). Из полученного списка на подозрении одна только команда paste

$ whatis paste

paste(1) - merge corresponding or subsequent lines of files

Точно! Читаем руководство. $ man paste

...

Вот и результат: $ paste left right

Система info

Альтернатива manpages - гипертекстовая система info(1). Info - часть системы документирования texinfo, разработанной GNU. У texinfo есть масса преимуществ перед roff. Во-первых, из texinfoдокументации можно изготавливать не только info-файлы, но и документы в формате HTML и XML, и даже настоящие книжки в формате TeX. Во-вторых, формат texinfo более новый, в нем существенно больше средств разметки, индексирования текста, организации таблиц и т. п. В- третьих, в отличие от man, info - система документирования, в которой на уровне просмотра реализован переход по гипертекстовым ссылкам.

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

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

Ссылка - один из двух видов гипертекстовых ссылок в info. При просмотре документации утилитой info достаточно переместить текстовый курсор при помощи клавиши Tab к нужному пункту меню и нажать enter, чтобы перейти к соответствующему узлу, т. е. проследовать по ссылке. Другой вид гипертекстовых ссылок называется перекрестными ссылками. Перекрестные ссылки возникают в тексте узла и указывают на какой-нибудь другой узел документа вне всякой иерархии. В книге перекрестная ссылка обычно возникает в случаях наподобие "эта тема подробнее рассматривается в гл. 3, разд. 7".

Индекс - сводное меню, содержащее ссылки на узлы, в описании которых помечено, что они этому меню принадлежат. Иными словами, индекс не надо писать вручную, он собирается при изготовлении info-файла из texinfo-документации. Несколько индексов в info-странице всегда определено, например, concept index - список всех сущностей, упоминающихся в документе.

36

Такая структура делает texinfo-документ пригодным для создания разветвленной и подробной документации: учебника, статьи, содержащей научные и исторические сведения, полного описания некоторой прикладной системы и т. д. Авторы texinfo-документа - сами разработчики этой системы, чаще всего независимой от какой-либо операционной среды. Под этим углом зрения можно рассматривать сообщество GNU, в котором документирование при помощи texinfo считается стандартом. Однако именно по причине независимости включать info-страницы в общее информационное пространство определенной ОС бывает затруднительно.

Тем самым texinfo занимает иную экологическую нишу, нежели man: документирование больших, сложных и замкнутых проектов. Для того чтобы поместить такую документацию в общий внутрисистемный информационный контекст, не нужно перелопачивать ее всю, в руководстве достаточно указать только основные принципы работы с установленным пакетом и поместить внешнюю ссылку на info-страницу, содержащую полную документацию. При этом страницу руководства сможет написать уже не разработчик прикладной системы, а тот, кто отвечает за включение ее в виде пакета в конкретную операционную среду (package maintainer).

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

37

4. Файловая система. Структура файловой системы. Монтируемые файловые системы. Интерфейс с файловой системой.

Файловая система UNIX характеризуется:

*иерархической структурой,

*согласованной обработкой массивов данных,

*возможностью создания и удаления файлов,

*динамическим расширением файлов,

*защитой информации в файлах,

*трактовкой периферийных устройств (таких как терминалы и ленточные устройства) как файлов.

Файловая система организована в виде дерева с одной исходной вершиной, которая называется корнем (записывается: "/"); каждая вершина в древовидной структуре файловой системы, кроме листьев, является каталогом файлов, а файлы, соответствующие дочерним вершинам, являются

					/
	+-------------		+------------		+---------		+---------	+---------	+
	|		|		|		|	|	|
	fsl		bin		etc		usr	unix	dev
+-+-+		+	---+---	+	|	+-+-+		+-+-+
|	|	|	|	|	|	|	|	|	|
mjb maury		sh	date who		passwd	src bin		tty00 tty01
						|
						|
						cmd
					+---	+	---+
					|		|
					date.c		who.c

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

пути "/etc/passwd", "/bin/who" и "/usr/src/cmd/who.c" указывают на файлы, являющиеся вершинами дерева, изображенного на Рисунке 1.2, а пути "/bin/passwd" и "/usr/ src/date.c" содержат неверный маршрут. Имя пути поиска необязательно должно начинаться с корня, в нем следует указывать маршрут относительно текущего для выполняемого процесса каталога, при этом предыдущие символы "наклонная черта" в имени пути опускаются. Так, например, если мы находимся в каталоге "/dev", то путь "tty01" указывает файл, полное имя пути поиска для которого

"/dev/tty01".

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

38

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

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

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

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

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

блоков.

Синтаксис вызова функции mount:

mount(special pathname,directory pathname,options);

где special pathname - имя специального файла устройства, соответствующего дисковому разделу с монтируемой файловой системой, directory pathname - каталог в существующей иерархии, где будет монтироваться файловая система (другими словами, точка или место монтирования), а options указывает, следует ли монтировать файловую систему "только для чтения" (при этом не будут выполняться такие функции, как write и creat, которые производят запись в файловую систему).

+ - - - - - - - - - - - - - - - - - - - - - - - - +

					/
|					|		|
		+----------------+--+-------------+					Корневая
|		|			|	|	| файловая
		bin			etc	usr	система
|		|			|	-	|
	+-----+-----+			+----+----+		-
|	|	|	|	|	|	-	|
	cc	date	sh	getty	passwd	-
+ - - - - - - - - - - - - - - - - - - - - - - - - +
						-
			+ - - - - - - - - - - - - - - - - - - - - - - - - +
						/
			|			|	|
	Файловая			+----------------+--+-------------+
						39

40

система из	|		|		|	|	|
раздела с			bin		include	src
именем	|		|		|	|	|
/dev/dsk1		+-----+-----+			|	|
	|	|	|	|	|	|	|
		awk	banner	yacc	stdio.h	uts
	+ - - - - - - - - - - - - - - - - - - - - - - - - +

Рисунок 5.22. Дерево файловых систем до и после выполнения функции mount Например, если процесс вызывает функцию mount следующим образом:

mount("/dev/dsk1","/usr",0);

ядро присоединяет файловую систему, находящуюся в дисковом разделе с именем "/dev/dsk1", к каталогу "/usr" в существующем дереве файловых систем (см. Рисунок 5.22). Файл "/dev/dsk1" является блочным специальным файлом, т.е. он носит имя устройства блочного типа, обычно имя раздела на диске. Ядро предполагает, что раздел на диске с указанным именем содержит файловую систему с суперблоком, списком индексов и корневым индексом. После выполнения функции mount к корню смонтированной файловой системы можно обращаться по имени "/usr". Процессы могут обращаться к файлам в монтированной файловой системе и игнорировать тот факт, что система может отсоединяться. Только системная функция link контролирует файловую систему, так как в версии V не разрешаются связи между файлами, принадлежащими разным файловым системам.

Ядро поддерживает таблицу монтирования с записями о каждой монтированной файловой системе. В каждой записи таблицы монтирования содержатся:

*номер устройства, идентифицирующий монтированную файловую систему (упомянутый выше логический номер файловой системы);

*указатель на буфер, где находится суперблок файловой системы;

*указатель на корневой индекс монтированной файловой системы ("/" для файловой системы с именем "/dev/dsk1" на Рисунке 5.22);

*указатель на индекс каталога, ставшего точкой монтирования (на Рисунке 5.22 это каталог "usr", принадлежащий корневой файловой системе).

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

+------------------------------------------------------------+
| алгоритм mount		|
| входная информация: имя блочного специального файла		|
|	имя каталога точки монтирования	|
|	опции ("только для чтения")	|
| выходная информация: отсутствует		|
| {		|
|	если (пользователь не является суперпользователем)	|
|	возвратить (ошибку);	|
|	получить индекс для блочного специального файла (алго- |
|	ритм namei);	|
|	проверить допустимость значений параметров;	|
|	получить индекс для имени каталога, где производится	|
|	монтирование (алгоритм namei);	|
|	если (индекс не является индексом каталога или счетчик |
|	ссылок имеет значение > 1)	|
|	{	|
|	освободить индексы (алгоритм iput);	|
|	возвратить (ошибку);	|
|	}	|
|	найти свободное место в таблице монтирования;	|
|	запустить процедуру открытия блочного устройства для	|
|	данного драйвера;	|
|	получить свободный буфер из буферного кеша;	|
|	считать суперблок в свободный буфер;	|