Контрольная работа по «Операционные системы»

Министерство Образования Российской Федерации

Ивановский государственный энергетический университет имени В.И. Ленина

Кафедра программного обеспечения компьютерных систем

 

 

 

 

 

 

 

 

 

Контрольная работа

по дисциплине «Операционные системы»

Вариант №3.

Выполнил: Студ. гр. 3-80к Лебедев Д.В. Шифр 911143К

Руководитель: Гадалов А.Б.

 

 

Иваново, 2014

 

Тема №1.

История, архитектура, основные концепции организации и функционирования ОС.

Вопрос №6.

Микроядерная архитектура ОС, ее достоинства и недостатки.

 

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

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

Рисунок 1.1 Перенос основного объема функций ядра в пользовательское пространство

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

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

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

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

Рисунок 1.2. Реализация системного вызова в микроядерной архитектуре

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

Преимущества и недостатки микроядерной архитектуры.

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

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

Основная проблема при использовании микроядерного подхода – что включать в микроядро, а что – выносить в пользовательское пространство. В результате ОС с такой архитектурой образуют некоторый спектр, на одном краю которого находятся системы с минимально возможным микроядром, состоящим только из средств передачи сообщений, а на другом – системы, в которых микроядро выполняет достаточно большой объем функций. Примером ОС второго типа является Windows NT, где с целью повышения производительности разработчики отклонились от микроядерной архитектуры и часто используемые функции графического интерфейса перенесли в ядро (начиная с версии 4.0) .

 

Тема №2.

Операционные системы Unix/Linux.

Вопрос №15.

Средства конфигурирования сети.

Настройка TCP/IP в Linux для работы в сети Ethernet

Для работы с сетевыми протоколами TCP/IP в Linux достаточно наличие только петлевого интерфейса, но если необходимо объединить хосты между собой, естественно, необходимо наличие сетевого интерфейса, каналов передачи данных (например витая пара), возможно, какого-либо сетевого оборудования. Так же, необходимо наличие установленных утилит для настройки сети (/sbin/ifconfig, /sbin/route и др.), обычно поставляемые в пакете net-tools. Так же необходимо наличие конфигурационных файлов для сети (например /etc/hosts) и поддержку сети ядром Linux.

Файлы настроек сети в Linux (конфигурационные файлы)

В целом, вся работа Linux основана на процессе init, который рождается при загрузке ОС и плодит своих потомков, которые в свою очередь и выполняют всю необходимую работу, будь то запуск bash или демона. Да, и вся загрузка Linux основана на скриптах bash, в которых прописана вся последовательность запуска мелких утилит с различными параметрами, которые последовательно запускаются/останавливаются при запуске/остановке системы. Аналогично запускается и сетевая подсистема Linux.

Каждый дистрибутив Linux имеет слегка отличающийся от других механизм инициализации сети, но общая картина, думаю, после прочтения будет ясна. Если просмотреть стартовые скрипты сетевой подсистемы какого-либо дистрибутива Linux, то, как настроить конфигурацию сети с помощью конфигурационных файлов, станет более-менее понятно, например у Debian (за основу возьмем этот дистрибутив) за инициализацию сети отвечает скрипт/etc/init.d/networking, просмотрев который, можно найти несколько функций, проверяющих наличие подключенных сетевых файловых систем (check_network_file_systems(), check_network_swap()), а так же проверку существования какого-то пока непонятного конфига /etc/network/options (функция process_options()),  а в самом низу, конструкцией case "$1" in проверяется первый параметр переданный скрипту и в соответствии с введенным параметром (start/stop/force-reload|restart или любое дугое) производит определенные действия. Из этих самых "определенных действий", на примере аргумента start видно, что сначала запускается функция process_options, далее отправляется в лог фраза Configuring network interfaces, и запускается команда ifup -a. Если посмотреть man ifup, то видно что данная команда читает конфиг из файла /etc/network/interfaces и согласно ключу -a запускает все интерфейсы имеющие параметр auto.

Соответственно, прочитав  man interfaces (rus) или man interfaces (eng) , становиться ясно, как же в Debian настроить какой-либо сетевой интерфейс с помощью конфига /etc/network/interfaces. Ниже, пример данного конфигурационного файла для 3х интерфейсов: петлевой (lo), со статичным IP (eth2) и IP получаемым по dhcp (eth0):

ip-server:~# cat /etc/network/interfaces

# This file describes the network interfaces available on your system

# and how to activate them. For more information, see interfaces(5).

 

# The loopback network interface

auto lo

iface lo inet loopback

 

# The primary network interface

allow-hotplug eth0

iface eth0 inet dhcp

 

allow-hotplug eth2

iface eth2 inet static

    address 192.168.1.1

    netmask 255.255.255.0

    gateway 192.168.1.254

    broadcast 192.168.1.255

В данном конфигураторе строки allow-hotplug и auto - это синонимы и интерфейсы будут подняты по команде ifup -a. Вот, собственно, и вся цепь работы сетевой подсистемы. Аналогично, в других дистрибутивах: в RedHat и SUSE сеть запускается скриптом /etc/init.d/network. Рассмотрев его, аналогично можно найти, где лежит конфигурация сети.

/etc/hosts

Данный файл хранит перечень IP адресов и соответствующих им (адресам) имен хостов.

ip-server:~# cat /etc/hosts

# ip        host.in.domain host

127.0.0.1       localhost

127.0.1.1       ip-server.domain.local  ip-server

192.168.1.1     ip-server.domain.local  ip-server

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

/etc/hostname

Данный файл содержит NetBIOS-имя хоста:

ip-server:~# cat /etc/hostname

ip-server

/etc/networks

Данный файл хранит имена и адреса локальной и других сетей. Пример:

ip-server:~# cat /etc/networks

default         0.0.0.0

loopback        127.0.0.0

link-local      169.254.0.0

home-network    192.168.1.0

При использовании данного файла, сетями можно управлять по имени. Например добавить маршрут не route add192.168.1.12, а route add home-network.

/etc/nsswitch.conf

Файл определяет порядок поиска имени хоста/сети, за данную настройку отвечают строки:

Для хостов:

hosts:          files dns

Для сетей:

networks:       files

Параметр files указывает использовать указанные файлы (/etc/hosts и /etc/networks соответственно), параметр dns указывает использовать службу dns.

/etc/host.conf

Файл задает параметры разрешения имен для резолвера

ip-server:~# cat /etc/host.conf

multi on

Данный файл  указывает библиотеке resolv - возвращать  все  допустимые адреса  узла, которые встретились в файле /etc/hosts, а не только первый из них.

/etc/resolv.conf

Данный фал определяет параметры механизма преобразования сетевых имен в IP адреса. Простым языком, определяет настройки DNS. Пример:

ip-server:~# cat /etc/resolv.conf

nameserver 10.0.0.4

nameserver 10.0.0.1

search domain.local

Первые 2 строчки указывают сервера DNS. Третья строка указывает домены поиска. Если при разрешении имени, имя не будет FQDN-именем, то данный домен подставиться в виде "окончания". Например, при выполнении команды ping host, пингуемый адрес преобразуется в host.domain.local. Остальные параметры можно почитать в man resolv.conf. Очень часто, в Linux используется динамическая генерация данного файла, с помощью т.н. программы/sbin/resolvconf. Данная программа является посредником между службами, динамически предоставляющими сервера имен (например DHCP client) и службами, использующими данные сервера имен. Для того чтобы использовать динамически генерируемый файл /etc/resolv.conf, необходимо сделать данный файл символической ссылкой на/etc/resolvconf/run/resolv.conf. В некоторых дистрибутивах путь может быть другой, об этом обязательно будет написано в man resolvconf.

Настройка сети

Ознакомившись с основными конфигурационными файлами, можно посмотреть на команды управления сетью. Выше уже говорилось о команде ifup, ifdown, но данные средства не совсем универсальны, допустим в дистрибутивах RH данных команд по умолчанию нет. Команды, описываемые ниже принадлежат пакету net-tools.

Чтобы быть уверенным в работоспособности команды в любом дистрибутиве Linux, необходимо пользоваться двумя основными командами. Это ifconfig, route и arp. Первая команда (ifconfig) отвечает за настройку сетевых интерфейсов (ip, маска, шлюз), вторая (route) - настройка маршрутизации, третья (arp) - управление arp-таблицей.  Хочется заметить, что выполнение данных команд без отключения стандартного скрипта запуска SystemV сетевой подсистемы внесет изменения только до первой перезагрузки/перезапуска сетевой службы, т.к. если пораскинуть мозгами, то можно понять, что скрипт /etc/init.d/networking при очередном запуске перечитает указанные выше конфигураторы и применит старые настройки. Соответственно, выход для постоянной установки настроек - либо команда ifconfig с соответствующими параметрами (вписать в rc.local), либо поправить руками соответствующие конфигураторы сетевых интерфейсов.

Так же, если выполняется команда ifconfig с недостающими параметрами (например, только IP адрес), то остальные дополняются автоматически (например бродкаст адрес добавляется по умолчанию с хостовым адресом, оканчивающимся на 255 и маска подсети по умолчанию берется 255.255.255.0).

Маршрутизация для имеющихся интерфейсов в современных ядрах всегда поднимается автоматически силами ядра. Вернее сказать, прямые маршруты в сеть согласно настроек IP и подсети, в которую смотрит поднятый интерфейс формируются автоматически, силами ядра. Поле gateway (шлюз) для таких записей показывает адрес выходного интерфейса или *. В старых версиях ядра необходимо было добавлять маршрут вручную командой route.