Семейство Unix
Обширное и бурно развивающееся семейство Unix оказало
огромное идейное влияние на развитие операционных систем в 80-е и 90-е
годы XX столетия. Генеалогия систем семейства опубликована на сайте [perso.wanadoo.fr]
и слишком обширна для того, чтобы ее можно было полностью привести в книге.
Применения систем семейства крайне разнообразны, начиная от встраиваемых
приложений реального времени, включая графические рабочие станции для
САПР и геоинформационных систем, и заканчивая серверами класса предприятия
и массивно параллельными суперкомпьютерами. Некоторые важные рыночные
ниши, например передачу почты и другие структурные сервисы Internet, системы
семейства занимают практически монопольно.
Родоначальником семейства следует, по-видимому, считать не первую версию
Unix, a Multics, совместно разрабатывавшуюся в 1965—1969 гг. General Electric
и Bell Laboratories. За это время General Electric выделило подразделение,
занимавшееся работами над Multics и аппаратной платформой для нее (GE-645),
в отдельную компанию Honeywell.
Multics была первой из промышленных систем, предоставлявших:
- создание процессов системным вызовом fork;
- страничную виртуальную память;
- отображение файлов в адресное пространство ОЗУ;
- вложенные каталоги;
- неструктурированные последовательные файлы;
- многопользовательский доступ в режиме разделения времени;
- управление доступом на основе ограниченных ACL (колец
доступа).
Multics оказала огромное влияние не только на разработчиков
Unix — значительные следы идейного влияния этой системы прослеживаются
так же в RSX-11 и VAX/VMS фирмы DEC. Последние Multics-системы были доступны
в Internet в 1997 г.
В 1969 г. Bell Laboratories отказалась от работ над Multics и начала разработку
собственной ОС для внутренних нужд. По-видимому, основной причиной этого
шага было осознание несоответствия между амбициозными целями проекта Multics
(ОС была весьма требовательна к ресурсам и могла работать только на больших
компьютерах Honeywell), в то время как материнской компании Bell Labs
— American Telephone & Telegraph — требовалась единая операционная
среда, способная работать на различных миникомпыотерах, используемых в
подразделениях телефонной сети США.
В Bell Laboratories был объявлен внутренний конкурс на разработку переносимой
ОС, способной работать на миникомпыотерах различных поставщиков. К проекту
были предъявлены следующие основные требования:
- многоплатформенность;
- вытесняющая многозадачность;
- многопользовательский доступ в режиме разделения времени;
- развитые телекоммуникационные средства.
Один из участников работ над Multics, К. Томпсон, разработал
крайне упрощенное ядро ОС, названное UNIX, для миникомпьютера PDP-7. К
1972 г. К. Томпсон и Д. Ритчи переписали ядро системы в основном на языке
С и продемонстрировали возможность переноса ОС на миникомпьютеры PDP-11.
Это обеспечило выполнение всех требований конкурса, и UNIX была признана
основной платформой для вычислительных систем, эксплуатируемых в AT&T.
Легенды доносят до нас более колоритные детали ранних этапов истории новой
системы. Так, одна из очень популярных легенд, излагаемая в той или иной
форме несколькими источниками, утверждает, что история UNIX началась с
разработанной для Multics игровой программы под названием Star Wars (звездные
войны — сама эта программа и даже правила игры до нас не дошли). Уволенный
из группы разработчиков Multics за разгильдяйство (мы приводим здесь наиболее
радикальный вариант легенды, не заботясь о его согласовании с историческими
фактами), Томпсон занялся "оживлением" неиспользуемой PDP-7,
стоявшей в углу машинного зала. Оживление заключалось в написании ядра
ОС, реализующего подмножество функциональности Multics, достаточное, для
того чтобы перенести и запустить его любимые Star Wars [Бах 1986].
Первые версии UNIX были рассчитаны на машины без диспетчера памяти. Процессы
загружались в единое адресное пространство. Ядро системы размещалось в
нижних адресах ОЗУ, начиная с адреса 0, и называлось сегментом
реентерабельных процедур. Реентерабельность обеспечивалась переустановкой
стека в момент системного вызова и запретом переключения задач на все
время исполнения модулей ядра. На машинах с базовой адресацией выполнялось
перемещение образов процессов по памяти и сброс образа процесса на диск
(задачный своппинг).
В Multics и современных системах Unix fork реализуется
посредством копирования страниц при модификации. Ранние версии UNIX физически
копировали образ процесса. Большая часть (по некоторым оценкам, до 90%)
fork немедленно продолжается исполнением системного вызова exec,
поэтому одной из первых оптимизаций, придуманных в университетских версиях
системы, было введение системного вызова vfork.
Порожденный этим вызовом процесс исполнялся на самом образе родителя,
а не на его копии. Создание нового образа процесса происходило только
при исполнении exec. Для того чтобы избежать возможных проблем взаимоисключения
(например, при вызове нереентерабельных функций стандартной библиотеки),
исполнение родителя приостанавливалось до тех пор, пока потомок не выполнит
exec или не завершится.
Выделяют [Баурн 1986] следующие отличительные особенности системы.
- Порождение процессов системным вызовом
fork, который создает копию адресного пространства в пользовательской
области процесса.
- Результат завершения процесса хранится в его дескрипторе
и может быть считан только родителем. В списке процессов такой дескриптор
выглядит как процесс в специальном состоянии, называемом зомби (zombie).
- Процессы-сироты (продолжающие исполнение после завершения
родителя) усыновляются процессом с идентификатором, равным 1.
- Процесс с идентификатором 1 запускается при загрузке
системы (по умолчанию это /bin/ink) и запускает все остальные обязательные
задачи в системе. Наличие такого процесса иногда объявляют необходимым
и достаточным критерием для причисления той или иной системы к семейству
Unix.
- Древовидная структура пространства имен файловой системы:
дополнительные ФС монтируются в те или иные точки корневой ФС и идентифицируются
затем точкой монтирования, а не именем устройства, на котором расположены.
- Файлы рассматриваются ОС как неструктурированные потоки
байтов и не типизованы на уровне ОС (в частности, на уровне ОС нет деления
файлов на записи).
- Файловая система поддерживает множественные имена файлов
в виде жестких и, у более поздних версий, символических связей.
- Отложенное удаление файлов: если процесс открыл файл,
а другой процесс его удалил, то первый процесс может продолжать работу
с файлом, и физическое удаление происходит только после того, как первый
процесс его закроет.
- Лозунг "все — файл", который, впрочем, последовательно
реализован только в экспериментальной системе Plan 9 — в реальных Unix
системах практически всегда присутствуют объекты, к которым не применимы
файловые операции: переменные среды, структуры данных ядра в ранних
версиях (позднее они были оформлены в виде псевдофайловой системы /ргос),
объекты SysV IPC и примитивы взаимоисключения POSIX Thread Library в
современных системах.
- Своеобразный командный язык, основанный на широком
применении переназначения ввода-вывода и конвейеров (последовательностей
задач, соединенных трубами).
Некоторые из перечисленных особенностей были позаимствованы
другими ОС. Так, переназначение ввода-вывода и конвейеры реализуются командными
процессорами ОС семейства СР/М, начиная с MS DOS 3.30. cmd.exe — командный
процессор OS/2 и Windows NT/2000/XP — даже правильно понимает конструкцию
cmdiine | more 2>&1. Стандартные командные
процессоры UNIX портированы практически на все современные ОС. Функциональный
аналог Korn Shell включен в стандартную поставку Windows 2000.
Жесткие связи файлов (однако, без отложенного удаления) поддерживаются
FCS2 (файловой системой VAX/VMS), NTFS и jfs при использовании под OS/2.
Точки монтирования (подключение дополнительных ФС в дерево каталогов существующей
ФС) реализованы в Windows 2000 и Toronto Virtual File System для OS/2.
Системный вызов CreateProcess Windows NT/2000/XP
может имитировать семантику fork: для этого
достаточно передать в качестве имени программы для нового процесса пустой
указатель.
Библиотека ЕМХ для OS/2 реализует fork при помощи
собственного обработчика страничного отказа. |