Размещено на http://www.allbest.ru/

3

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«МИРЭА - Российский технологический университет»

РТУ МИРЭА

Институт информационных технологий (ИТ)

Кафедра вычислительной техники (ВТ)

Реферат

ОПЕРАЦИОННАЯ СИСТЕМА UNIX

Выполнил студент группы

ИНБО-04-18 Назаров Ш.Х.

Принял ассистент кафедры ВТ

Пономарев А.Н.

Москва 2020

Содержание

операционный система unix программный

Назначение OC и история создания

Структура и ядро ОС

Процессы и потоки

Управления памятью

Управления вводом-выводом

Файловая система

Особенности

Достоинства и недостатки

Заключения

Назначение ОС и история создания

UNIX зародился в лаборатории Bell Labs фирмы AT&T более 30 лет назад. В то время Bell Labs занималась разработкой многопользовательской системы разделения времени MULTICS (Multiplexed Information and Computing Service) совместно с MIT и General Electric, но эта система потерпела неудачу. Bell Labs отказалась от участия в проекте MULTICS, что дало возможность одному из ее исследователей, Кену Томпсону, заняться поисковой работой в направлении улучшения операционной среды Bell Labs. Томпсон, а также сотрудник Bell Labs Денис Ритчи и некоторые другие разрабатывали новую файловую систему, многие черты которой вели свое происхождение от MULTICS. Для проверки новой файловой системы Томпсон написал ядро ОС и некоторые программы для компьютера GE-645, который работал под управлением мультипрограммной системы разделения времени GECOS. У Кена Томпсона была написанная им еще во времена работы над MULTICS игра "Space Travel" - "Космическое путешествие". Он запускал ее на компьютере GE-645, но она работала на нем не очень хорошо из-за невысокой эффективности разделения времени. Кроме этого, машинное время GE-645 стоило слишком дорого. В результате Томпсон и Ритчи решили перенести игру на машину PDP-7 фирмы DEC, имеющую 4096 18-битных слов, телетайп и хороший графический дисплей. Но у PDP-7 было неважное программное обеспечение, и, закончив перенос игры, Томпсон решил реализовать на PDP-7 ту файловую систему, над который он работал на GE-645. Из этой работы и возникла первая версия UNIX. Уже тогда она включала характерную для современной UNIX файловую систему, основанную на индексных дескрипторах inode, имела подсистему управления процессами и памятью, а также позволяла двум пользователям работать в режиме разделения времени. Система была написана на ассемблере. Имя UNIX (Uniplex Information and Computing Services) было дано ей одним сотрудником Bell Labs, Брайаном Керниганом,

Первыми пользователями UNIX'а стали сотрудники отдела патентов Bell Labs, которые нашли ее удобной средой для создания текстов. Большое влияние на судьбу UNIX оказала перепись ее на языке высокого уровня С, разработанного Денисом Ритчи специально для этих целей. Это произошло в 1973 году, UNIX насчитывал к этому времени уже 25 инсталляций, и в Bell Labs была создана специальная группа поддержки UNIX.

После описания системы Томпсоном и Ритчи в компьютерном журнале CACM в 1974 г. UNIX получил широкое распространение. ОС стала востребована в университетах, так как для них она поставлялась бесплатно вместе с исходными кодами на С. Широкое распространение эффективных C-компиляторов сделало UNIX уникальной для того времени ОС из-за возможности переноса на различные компьютеры. Университеты внесли значительный вклад в улучшение UNIX и дальнейшую его популяризацию. Еще одним шагом на пути к признанию UNIX, как стандартизованной среды стала разработка Денисом Ритчи библиотеки ввода-вывода stdio. Благодаря использованию этой библиотеки для компилятора С, программы для UNIX стали легко переносимыми.

ОС UNIX является интерактивной операционной системой, это традиционно сетевая операционная система.

Структура и ядро ОС

Ядро

Центром ОС является, как было сказано, менеджер ресурсов и планировщик задач. Функции этих частей системы востребованы, пока есть хоть одна задача (т. е. всегда), функции к тому же работают в режиме супервизора. В UNIX они составляют ядро системы (kernel). Ядро постоянно находится в памяти, обслуживая непрерывный поток запросов на использование универсальных ресурсов системы: памяти и времени. В ядро UNIX, кроме того, входит реализация сетевых протоколов (были попытки выделить стек протоколов TCP/IP в отдельный модуль, но это многократно снижает производительность, поскольку реализация некоторых особенностей TCP/IP, как ни странно, требует жесткой привязки к внешним устройствам и структурам ядра ). Ядро UNIX предоставляет программам пользователя унифицированный интерфейс к ресурсам компьютера (так называемые системные вызовы, system calls) и содержит всю непростую логику распределения ресурсов по задачам, которые в UNIX называются процессами.

Рис. 5.1 Структура UNIX как операционной среды

На самом деле далеко не все, что работает в режиме ядра (супервизора), обязано присутствовать в конкретной системе, запущенной на конкретном компьютере. Функции, отвечающие за работу с самыми разнообразными внешними устройствами (которые отличаются логикой работы), бессмысленно включать в ядро все сразу. Отдельно взятый компьютер не содержит и сотой части всех устройств, поддерживаемых системой. Более того, зачастую весьма трудно автоматически определить марку устройства, подключенного к системе; еще труднее, не имея обширнейшей базы данных по всем устройствам, определить, какому из известных устройств соответствует найденное системой неизвестное, и вообще соответствует ли (т. е. можно ли с ним работать как с несколько иным, но известным). А вот администратору системы достаточно для этого посмотреть маркировку на самой плате или почитать документацию. Так мы приходим к понятию драйвера устройства ("драйвер" по-английски будет handler, а слово driver используется для обозначения устройства, которое что-нибудь крутит или тащит, например лентопротяжного. Однако пишущие по-английски носители других языков часто говорят driver вместо handler... Путаница неизбежна, если не вникать каждый раз в то, о чем речь). Драйверы включаются в состав ядра, если соответствующие им устройства входят (или могут входить) в состав компьютера. Одни драйверы (скажем, шины PCI) есть в системе почти всегда, другие написаны специально для контроллера какого-нибудь экзотического устройства. Существуют драйверы, которые не являются интерфейсной частью внешнего устройства, а реализуют дополнительную функциональность самой системы (скажем, драйвер файловой системы ISO9660, которая используется на лазерных дисках).

В старых версиях UNIX (основанных непосредственно на BSD4.3 или UNIX SystemV различных редакций) все драйверы приходилось заранее прикомпоновывать к ядру (т. е. пользоваться компоновщиком ld, таким же, какой применяется при сборке программ). Более того, запуск ld был своеобразной уступкой коммерческих версий UNIX его некоммерческому духу, потому что на самом деле драйверы компилировались из исходных текстов на языке Си, как и все ядро системы (так было, например, в FreeBSD3.* и в Linux до версии 1.2). Процесс компиляции ядра системы из исходных текстов или компоновки его из объектных модулей носит название сборки (пересборки) ядра и во многих системах практикуется и по сей день.

С увеличением размеров оперативной памяти отпала необходимость экономить байты на сборке ядра, в точности соответствующего имеющемуся профилю оборудования. Разработчики стараются собрать ядро, содержащее драйверы всех самых популярных устройств, чтобы оно, не занимая слишком много памяти, могло управлять системой на подавляющем большинстве компьютеров. Такое ядро называется базовым (generic). Поскольку для пересборки ядра необходимы многие знания (как минимум, нужно разбираться в архитектуре используемой версии UNIX, в архитектуре ЭВМ и в особенности внешних устройств ), а нужда в этом может возникнуть при первой же установке системы, хорошо укомплектованное базовое ядро во многом облегчает жизнь неопытному пользователю.

Модули ядра

Если базового ядра все-таки недостаточно, в современных системах многие драйверы можно загружать динамически, из модулей ядра. Ядро, уже работающее в памяти, можно дополнить, загрузив такой модуль из файла специального формата, после чего перекомпоновать ядро на ходу (специальным компоновщиком). В эти модули можно вынести необязательные функциональности системы (например, фильтрацию сетевых пакетов ), после чего базовое ядро станет еще меньше, однако процесс загрузки усложнится, так как некоторые из подгружаемых модулей понадобятся ядру уже при старте системы, когда доступа к файлам может и не быть. Типичный пример: для работы с диском ядру нужен драйвер дискового массива (RAID-контроллера), который вместе с программой загрузки и компоновки модулей на этом массиве и находится. Разные системы выходят из этой ситуации по-разному.

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

Демоны

Прочие части UNIX запускаются уже как процессы в режиме пользователя. С ядром взаимодействуют функциональные подсистемы (службы), то есть наборы программных средств, выполняющих определенную функцию (например, система печати, система передачи почты и т. д.). Управляющий центр функциональной подсистемы - так называемый демон (daemon, в переводах с греческого называемый "даймон"). Как сказано в "Руководстве системного администратора UNIX " ( [ 33 ] ), "Даймон не служит ни злу, ни добру, он только определяет характер и личность человека. Он больше похож на ангела-хранителя...". Наличие рогов и трезубца у демонов BSD еще ни о чем не говорит, например, демона FreeBSD зовут совсем по-человечески - Чак (Chuck). Существо, появляющееся в Linux, хоть и зовется Такс (Tux), не имеет ни рогов, ни трезубца, потому что "по национальности" - пингвин. Демон - это процесс, который запускается при старте UNIX для обслуживания запросов к функциональной подсистеме. Пользователю запускать его незачем, он работает всегда. Именно демон обменивается данными с ядром системы, часто он держит очередь пользовательских запросов, работает с сетью и т. д.

Утилиты

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

Слово " утилиты " (utilities) буквально означает "полезности". Утилиты - это программы, которые могут понадобиться при решении всевозможных задач. Если есть высокая вероятность, что некоторая программа может понадобиться более чем одному пользователю для решения более чем одной задачи, то ее стоит включить в систему. Таких пользовательских утилит в UNIX еще больше, чем системных (чем определенно нарушается принцип У контекста; о том, как устранить это нарушение, речь пойдет в лекции 6). Множество пользовательских утилит занимается преобразованием текста, так как текстовый файл - универсальное пространство для создания умопостижимых моделей. Немало утилит помогает при разработке решений: компиляторы, отладчики, редакторы диаграмм, трассировщики и т. д. Почти всеми пользовательскими утилитами пользуется система, потому что при проективном подходе вообще невозможно провести четкую границу между системным и пользовательским наполнением. К обеим категориям, например, относятся утилиты для работы с файлами и файловой системой или интерпретатор командной строки (shell). На shell написаны все системные сценарии, поскольку он представляет собой еще и удобный высокоуровневый язык программирования.

Программные продукты и пакеты

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

Для того чтобы оперативно добавлять программный продукт в систему или удалять его оттуда, необходимо заранее договориться о размещении в файловой системе всех входящих в него файлов. Запомнив каждый файл с полным именем, мы получим архив, целиком определяющий расположение программного продукта в системе. Такой архив в UNIX называется пакетом. Мы можем устанавливать пакет в систему и удалять его, зная, что записываем и удаляем файлы, принадлежащие только ему. В пакете могут храниться не только программные продукты, но и вообще любые "кирпичики", из которых можно складывать систему: утилиты, драйверы, документация, шрифты и все остальное. Если при установке или удалении пакета нужно проделать какие-нибудь действия (например, зарегистрировать устанавливаемый шрифт), к нему прилагаются установочный сценарий и сценарий удаления.

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

Процессы и потоки

Под пользовательским контекстом процесса понимают код и данные, расположенные в адресном пространстве процесса. Все данные подразделяются на:

· инициализируемые неизменяемые данные (например, константы);

· инициализируемые изменяемые данные (все переменные, начальные значения которых присваиваются на этапе компиляции);

· неинициализируемые изменяемые данные (все статические переменные, которым не присвоены начальные значения на этапе компиляции);

· стек пользователя;

· данные, расположенные в динамически выделяемой памяти (например, с помощью стандартных библиотечных C функций malloc(), calloc(), realloc() ).

Исполняемый код и инициализируемые данные составляют содержимое файла программы, который исполняется в контексте процесса. Пользовательский стек применяется при работе процесса в пользовательском режиме (user-mode).

Рис. 3-4.1 Контекст процесса в UNIX

Под понятием "контекст ядра" объединяются системный контекст и регистровый контекст, рассмотренные на лекции. Мы будем выделять в контексте ядра стек ядра, который используется при работе процесса в режиме ядра (kernel mode), и данные ядра, хранящиеся в структурах, являющихся аналогом блока управления процессом -- PCB. Состав данных ядра будет уточняться на последующих семинарах. На этом занятии нам достаточно знать, что в данные ядра входят: идентификатор пользователя -- UID, групповой идентификатор пользователя -- GID, идентификатор процесса -- PID, идентификатор родительского процесса -- PPID.

Идентификация процесса

Каждый процесс в операционной системе получает уникальный идентификационный номер - PID (process identificator). При создании нового процесса операционная система пытается присвоить ему свободный номер больший, чем у процесса, созданного перед ним. Если таких свободных номеров не оказывается (например, мы достигли максимально возможного номера для процесса), то операционная система выбирает минимальный номер из всех свободных номеров. В операционной системе Linux присвоение идентификационных номеров процессов начинается с номера 0, который получает процесс kernel при старте операционной системы. Этот номер впоследствии не может быть присвоен никакому другому процессу. Максимально возможное значение для номера процесса в Linux на базе 32-разрядных процессоров Intel составляет 2³¹-1.

Состояния процесса. Краткая диаграмма состояний

Модель состояний процессов в операционной системе UNIX представляет собой детализацию модели состояний, принятой в лекционном курсе. Краткая диаграмма состояний процессов в операционной системе UNIX изображена на рисунке 3-4.2.

Рис. 3-4.2 Сокращенная диаграмма состояний процесса в UNIX

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

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

Иерархия процессов

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

Таким образом, все процессы в UNIX связаны отношениями процесс-родитель - процесс-ребенок и образуют генеалогическое дерево процессов. Для сохранения целостности генеалогического дерева в ситуациях, когда процесс-родитель завершает свою работу до завершения выполнения процесса-ребенка, идентификатор родительского процесса в данных ядра процесса-ребенка (PPID - parent process identificator) изменяет свое значение на значение 1, соответствующее идентификатору процесса init, время жизни которого определяет время функционирования операционной системы. Тем самым процесс init как бы усыновляет осиротевшие процессы. Наверное, логичнее было бы заменять PPID не на значение 1, а на значение идентификатора ближайшего существующего процесса-прародителя умершего процесса-родителя, но в UNIX почему-то такая схема реализована не была.

Системные вызовы getppid() и getpid()

Данные ядра, находящиеся в контексте ядра процесса, не могут быть прочитаны процессом непосредственно. Для получения информации о них процесс должен совершить соответствующий системный вызов. Значение идентификатора текущего процесса может быть получено с помощью системного вызова getpid(), а значение идентификатора родительского процесса для текущего процесса - с помощью системного вызова getppid(). Прототипы этих системных вызовов и соответствующие типы данных описаны в системных файлах <sys/types.h> и <unistd.h>. Системные вызовы не имеют параметров и возвращают идентификатор текущего процесса и идентификатор родительского процесса соответственно.

Системные вызовы getpid() и getppid()

Прототипы системных вызовов

#include <sys/types.h>

#include <unistd.h>

pid_t getpid(void);

pid_t getppid(void);

Описание системных вызовов

Системный вызов getpid возвращает идентификатор текущего процесса.

Системный вызов getppid возвращает идентификатор процесса-родителя для текущего процесса.

Тип данных pid_t является синонимом для одного из целочисленных типов языка C.

Написание программы с использованием getpid() и getppid()

В качестве примера использования системных вызовов getpid() и getppid() самостоятельно напишите программу, печатающую значения PID и PPID для текущего процесса. Запустите ее несколько раз подряд. Посмотрите, как меняется идентификатор текущего процесса. Объясните наблюдаемые изменения.

Управление памятью

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

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

Размещено на Allbest.ru