Способы реализации прикладных программных сред. Прикладное программное обеспечение Способы реализации прикладных программных средств

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

Совместимость приложений может быть на двоичном уровне и на уровне исходных текстов [13 ]. Приложения обычно хранятся в ОС в виде исполняемых файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость достигается в том случае, если можно взять исполняемую программу и запустить ее на выполнение в среде другой ОС.

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

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

Вид возможной совместимости зависит от многих факторов. Самый главный из них – архитектура процессора. Если процессор применяет тот же набор команд (возможно, с добавлениями, как в случае IBM PC: стандартный набор + мультимедиа + графика + потоковые) и тот же диапазон адресов, то двоичная совместимость может быть достигнута достаточно просто. Для этого необходимо соблюдение следующих условий:

API, который использует приложение, должен поддерживаться данной ОС;

внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной ОС.

Если процессоры имеют разную архитектуру, то, кроме перечисленных условий, необходимо организовать эмуляцию двоичного кода. Например, широко используется эмуляция команд процессора Intel на процессоре Motorola 680x0 компьютера Macintosh. Программный эмулятор в этом случае последовательно выбирает двоичную инструкцию процессора Intel и выполняет эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как у процессора Motorola нет в точности таких же регистров, флагов, внутреннего АЛУ и др., как в процессорах Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти.

Это простая, но очень медленная работа, поскольку одна команда Intel выполняется значительно быстрее, чем эмулирующая ее последовательность команд процессора Motorola. Выходом в таких случаях является применение так называемых прикладных программных сред или операционных сред. Одной из составляющих такой среды является набор функций интерфейса прикладного программирования API, который ОС предоставляет своим приложениям. Для сокращения времени на выполнение чужих программ прикладные среды имитируют обращение к библиотечным функциям.

Эффективность этого подхода связана с тем, что большинство сегодняшних программ работает под управлением GUI (графических интерфейсов пользователя) типа Windows, MAC или UNIX Motif, при этом приложения тратят 60-80% времени на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программ. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие библиотеки GUI, но написанные на "родном" коде. Таким образом, достигается существенное ускорение выполнения программ с API другой операционной системы. Иначе такой подход называют трансляцией – для того, чтобы отличить его от более медленного процесса эмулирования по одной команде за раз.

Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel производительность может быть очень низкой. Но когда производится вызов функции GUI, открытие окна и др., модуль ОС, реализующий прикладную среду Windows, может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а, возможно, и превзойти) скорость работы на своём родном процессоре.

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

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

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

На рис. 1.9 ОС OS1 поддерживает кроме своих "родных" приложений приложения операционных систем OS2 и OS3. Для этого в её составе имеются специальные приложения, прикладные программные среды, которые транслируют интерфейсы "чужих" операционных систем API OS2 и API OS3 в интерфейс своей "родной" ОС – API OS1. Так, например, в случае если бы в качестве OS2 выступала ОС UNIX, а в качестве OS1 – OS/2, для выполнения системного вызова создания процесса fork () в UNIX-приложении программная среда должна обращаться к ядру операционной системы OS/2 с системным вызовом DOS ExecPgm ().

Рис. 1.9. Организация множественных прикладных сред

К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой ОС. Например, чтобы функция создания процесса в OS/2 Dos ExecPgm () полностью соответствовала функции создания процесса fork () в UNIX-подобных системах, её нужно было бы изменить и прописать новую функциональность: поддержку возможности копирования адресного пространства родительского процесса в пространство процесса-потомка [17 ].

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

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

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микро ядерной архитектуры, в частности:

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

при отказе одной из прикладных сред остальные сохраняют работоспособность, что способствует надежности и стабильности системы в целом;

низкая производительность микроядерных ОС сказывается на скорости работы прикладных средств, а значит, и на скорости работы приложений.

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

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

Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В операционных системах, построенных с использовани­ем микроядерной концепции, таких, как, например, Windows NT, прикладные среды выполняются в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в операционную систему.

Один из наиболее очевидных вариантов реализации множественных приклад­ных сред основывается на стандартной многоуровневой структуре ОС. На рис. 3. 8 операционная система OS1 поддерживает кроме своих «родных» приложений приложения операционной системы OS2. Для этого в ее составе имеется специальное приложение – прикладная программная среда, которая транс­лирует интерфейс «чужой» операционной системы –API OS2 в ин­терфейс своей «родной» операционной системы – API OS1.

Рис. 3. 8. Прикладная программная среда, транслирующая
системные вызовы

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных програм-мных интерфейсов. В приведенном на рис. 3. 9примере операционная си-стема поддерживает прило­жения, написанные для OS1, OS2 и OS3. Для этого непосредственно в простран­стве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3.

Рис. 3. 9. Реализация совместимости на основе нескольких
равноправных API

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

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

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

Рис. 3. 10. Микроядерный подход к реализации множественных
прикладных сред

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

· очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС;

· надежность и стабильность выражаются в том, что при отказе одной из при­кладных сред все остальные сохраняют работоспособность;

· низкая производительность микроядерных ОС сказывается на скорости рабо­ты прикладных сред, а значит, и на скорости выполнения приложений.

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

Вопросы для самопроверки

1. Что понимают под архитектурой ОС?
2. Какие три основных слоя принято выделять в структуре вычислительной системы?
3. Какая роль возложена ОС на интерфейс системных вызовов?
4. Какие условия при проектировании ОС должны быть соблюдены с тем, чтобы ОС была легко переносимой?
5. В чем отличие микроядерной архитектуры от традиционной архитектуры ОС?
6. Почему микроядро хорошо подходит для поддержки распределенных вычислений?
7. Что подразумевается под концепцией множественных прикладных сред?
8. В чем суть метода трансляции библиотек?

Конец работы -

Эта тема принадлежит разделу:

Операционная система, процессы, оборудование

Операционная система ос в наибольшей степени определяет облик всей вычислительной системы в целом ос выполняет две по существу мало связанные.. ос как виртуальная расширенная машина использование большинства компьютеров.. с точки зрения пользователя функцией ос является предоставление пользователю некоторой расширенной или виртуальной..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Особенности аппаратных платформ
На свойства операционной системы непосредственное влияние оказывают аппаратные средства, на которые она ориентирована. По типу аппаратуры различают операционные системы персональных компьютеров, ми

Задачи и упражнения
1. Какие события в развитии технической базы вычислительных машин стали вехами в истории операционных систем? 2. В чем состояло принципиальное отличие первых мониторов пакетной обработки о

Архитектура операционной системы
Любая хорошо организованная сложная система имеет понятную и рациональную структуру, то есть разделяется на части - модули, имеющие вполне законченное функциональное назначение с че

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

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

Подсистема управления файлами
Файл представляет собой набор взаимосвязанной информации, определенной при создании. Кроме собственно данных, файлы представляют программы, как в исходном, так и в объектном виде. Подсисте

Сетевое обеспечение
Распределенная система - набор процессоров, которые не распределяют память или каждый процессор имеет свою локальную память. Процессоры в системе соединены посредством компьютерной сети и обеспечив

Ядро и вспомогательные модули ОС
Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы: ядро - модули ОС, выполняющие основные функции;

Ядро и привилегированный режим
Для надежного управления ходом выполнения приложений операционная система должна иметь по отношению к приложениям определенные привилегии. Иначе некорректно работающее приложение мо

Многослойная структура ОС
Вычислительную систему, работающую под управлением ОС на основе ядра, можно рассматривать как систему, состоящую из трех иерархически расположенных слоев: нижний слой образует аппар

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

Аппаратная зависимость и переносимость ОС
Многие операционные системы успешно работают на различных аппаратных платформах без существенных изменений в своем составе. Во многом это объясняется тем, что, несмотря на различия

Переносимость операционной системы
Если код операционной системы может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную пл

Концепция
Микроядерная архитектура является альтернативой классическому способу построения операционной системы. Под классической архитектурой в данном случае понимается рассмотренная выше структурная органи

Двоичная совместимость и совместимость исходных текстов
Необходимо различать совместимость на двоичном уровне и совместимость на уровне исходных текстов. Приложения обычно хранятся в ОС в виде исполняемых файлов, содержащих двоичные обра

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

Понятие процесса
Процессом называется некоторая деятельность, выполняемая на процессоре. Процессором в широком смысле называется любое устройство в составе ЭВМ, спо

Понятие ресурса
Одной из функций ОС является обеспечение эффективного и бесконфликтного способа управления ресурсами вычислительной системы. Под ресурсом часто понимается показатель

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

Одноочередные дисциплины обслуживания
а) FIFO (First In -- First Out) – дисциплина обслуживания в порядке поступления. Все заявки поступают в конец очереди. Первыми обслуживаются заявки, находящиеся в начале очереди. Схематическ

Система прерываний
Ситуация, которая возникает в результате воздействия какого-то независимого события, приводящего к временному прекращению выполнения последовательности команд одной программы с цель

Понятие процесса
Процесс(задача) - программа, находящаяся в режиме выполнения. С каждым процессом связывается его адресное пространство, из которого он может читать и в ко

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

Завершение процесса
(вызов exit или ExitProcess): Плановое завершение (окончание выполнения) Плановый выход по известной ошибке (например, отсутствие файла)

Иерархия процессов
В UNIX системах заложена жесткая иерархия процессов. Каждый новый процесс созданный системным вызовом fork, является дочерним к предыдущему процессу. Дочернему процессу достаются от родительского п

Состояние процессов
Три состояния процесса: Выполнение (занимает процессор) Готовность (процесс временно приостановлен, чтобы позволить выполняться другому процессу) Ожидание (процесс

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

Модель потока
С каждым потоком связывается: Счетчик выполнения команд Регистры для текущих переменных Стек Состояние Потоки делят между собой элементы

Преимущества использования потоков
Упрощение программы в некоторых случаях, за счет использования общего адресного пространства. Быстрота создания потока, по сравнению с процессом, примерно в 100 раз. Повышен

Реализация потоков в пространстве пользователя, ядра и смешанное
А - потоки в пространстве пользователя B

Особенности реализации Windows
Используется четыре понятия: Задание - набор процессов с общими квотами и лимитами Процесс - контейнер ресурсов (память...), содержит как минимум один поток. Пото

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

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

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

Критические области
Критическая область - часть программы, в которой есть обращение к совместно используемым данным. Условия избегания состязания и эффективной работы процессов: Два процесса не

Переменные блокировки
Вводится понятие переменной блокировки, т.е. если значение этой переменной равно, например 1, то ресурс занят другим процессом, и второй процесс переходит в режим ожидания (блокируется) до тех пор,

Строгое чередование
В этой модели, процессы могут выполняться строго по очереди, используя переменную.

Примитивы взаимодействия процессов
Вводится понятия двух примитивов. sleep - системный запрос, в результате которого вызывающий процесс блокируется, пока его не запустит другой процесс. wak

Семафоры
Семафоры - переменные для подсчета сигналов запуска, сохраненных на будущее. Были предложены две операции down и up (аналоги sleep и wake

Планирование в системах пакетной обработки
6.2.1 "Первый пришел - первым обслужен" (FIFO - First In Fist Out) Процессы ставятся в очередь по мере поступления. Преимущества:

Циклическое планирование
Самый простой алгоритм планирования и часто используемый. Каждому процессу предоставляется квант времени процессора. Когда квант заканчивается процесс переводится планировщиком в конец оче

Приоритетное планирование
Каждому процессу присваивается приоритет, и управление передается процессу с самым высоким приоритетом. Приоритет может быть динамический и статический. Динамичес

Планирование в системах реального времени
Системы реального времени делятся на: жесткие (жесткие сроки для каждой задачи) - управление движением гибкие (нарушение временного графика не желательны, но допустимы) - уп

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

Взаимоблокировка процессов
Взаимоблокировка процессов может происходить, когда несколько процессов борются за один ресурс. Ресурсы бывают выгружаемые и невыгружаемые, аппаратные и программные.

Моделирование взаимоблокировок
Моделирование тупиков с помощью графов. Условные обозначения На такой модели оч

Обнаружение и устранение взаимоблокировок
Система не пытается предотвратить взаимоблокировку, а пытается обнаружить ее и устранить. Обнаружение взаимоблокировки при наличии одного ресурса каждого типа

Динамическое избежание взаимоблокировок
В этом способе ОС должна знать, является ли предоставление ресурса безопасным или нет. Траектории ресурсов Рассмотрим модель из двух процессов и двух ресурсов

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

Принципы аппаратуры ввода-вывода
Два нижних уровня системы управления вводом-выводом составляет hardware: сами устройства, непосредственно выполняющие операции, и их контроллеры, служащие для организации совместной работы устройст

Контроллеры устройств
Устройства ввода-вывода обычно состоят из двух частей: механическая (не надо понимать дословно) - диск, принтер, монитор электронная - контроллер или

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

Прямой доступ к памяти (DMA - Direct Memory Access)
Прямой доступ к памяти реализуется с помощью DMA - контроллера. Контроллер содержит несколько регистров: регистр адреса памяти счетчик байтов

Прерывания
После того как устройство ввода-вывода начало работу, процессор переключается на другие задачи. Чтобы сигнализировать процессору об окончании работы, устройство инициализирует прерывание,

Задачи программного обеспечения ввода-вывода
Основные задачи, которые должно решать программное обеспечение ввода-вывода: Независимость от устройств - например, программа, читающая данные из файла не должна задумываться с чего

Программный ввод-вывод
В этом случае всю работу выполняет центральный процессор. Рассмотрим процесс печати строки ABCDEFGH этим способом.

Управляемый прерываниями ввод-вывод
Если в предыдущем примере буфер не используется, а принтер печатает 100 символов в секунду, то на каждый символ будет уходить 10мс, в это время процессор будет простаивать, ожидая готовности принте

Обработчики прерываний
Прерывания должны быть скрыты как можно глубже в недрах операционной системы, чтобы как можно меньшая часть ОС имела с ними дело. Лучше всего блокировать драйвер, начавший ввод-вывод. Алго

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

Независимое от устройств программное обеспечение ввода-вывода
Функции независимого от устройств программного обеспечения ввода-вывода: Единообразный интерфейс для драйверов устройств, Буферизация Сообщения об ошибках

Обобщение уровней и функций ввода-вывода
Уровни и основные функции системы ввода-вывода Баз

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

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

Spooling и захват устройств
О понятии spooling мы говорили в первой лекции нашего курса, как о механизме, впервые позволившем совместить реальные операции ввода-вывода одного задания с выполнением другого зад

Обработка прерываний и ошибок
Если при работе с внешним устройством вычислительная система не пользуется методом опроса его состояния, а задействует механизм прерываний, то при возникновении прерывания, как мы уже

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

Принципы, заложенные в подсистему управления вводом-выводом в ОС UNIX
1. Эта подсистема построена единообразно с подсистемой управления данными (файловой системой). Пользователю предоставляется унифицированный способ доступа как к ПУ, так и к файлам. Под файлом в ОС

Управление памятью в ОС
4.1. Понятие об организации и управлении физической памятью в операционных системах 4.2. Методы связного распределения основной памяти 4.2.1. Связное распределен

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

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

Связное распределение памяти при мультипрограммной обработке
При мультипрограммной обработке в памяти компьютера размещается сразу несколько заданий. Распределение памяти между заданиями в этом случае может быть выполнено следующими способами: · рас

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

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

Страничная организация виртуальной памяти
Виртуальный адрес при чисто страничной организации памяти _ это упорядоченная пара (p, d), где p - номер страницы в виртуальной памяти, а d - смещение в рамках страницы p. Процесс может выполняться

Сегментная организация виртуальной памяти
Виртуальный адрес при сегментной организации виртуальной памяти - это упорядоченная пара n = (s, d) , где s - номер сегмента виртуальной памяти, а d - смещение в рамках этого сегмента. Процесс мож

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

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

Стратегии вталкивания (подкачки)
Для управления вталкиванием применяются следующие стратегии: · вталкивание (подкачка) по запросу (по требованию); · вталкивание (подкачка) с упреждением (опережением).

Стратегии размещения
В системах со страничной организацией виртуальной памяти решение о размещении вновь загружаемых страниц принимается достаточно просто: новая страница может быть помещена в любой свободный

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

Именование файлов
Длина имени файла зависит от ОС, может быть от 8 (MS-DOS) до 255 (Windows, LINUX) символов. ОС могут различать прописные и строчные символы. Например, WINDOWS и windows для MS-DOS одно и т

Структура файла
Три основные структуры файлов: 1. Последовательность байтов - ОС не интересуется содержимым файла, она видит только байты. Основное преимущество такой системы, это гибкост

Типы файлов
Основные типы файлов: · Регулярные - содержат информацию пользователя. Используются в Windows и UNIX. · Каталоги - системные файлы, обеспечивающи

Атрибуты файла
Основные атрибуты файла: · Защита - кто, и каким образом может получить доступ к файлу (пользователи, группы, чтение/запись). Используются в Windows и UNIX. · Пароль - пароль к фа

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

Одноуровневые каталоговые системы
В этой системе все файлы содержатся в одном каталоге. Од

Имя пути
Для организации дерева каталогов нужен некоторый способ указания файла. Два основных метода указания файла: · абсолютное имя пути - указывает путь от корневого ка

Реализация каталогов
При открытии файла используется имя пути, чтобы найти запись в каталоге. Запись в каталоге указывает на адреса блоков диска. В зависимости от системы это может быть: · дисковый ад

Реализация длинных имен файлов
Раньше операционные системы использовали короткие имена файлов, MS-DOS до 8 символов, в UNIX Version 7 до 14 символов. Теперь используются более длинные имена файлов (до 255 символов и больше).

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

А - совместно используемый файл
Такая файловая система называется ориентированный ациклический граф(DAG, Directed Acyclic Graph). Возникает проблема, если дисковые адреса содержатся в самих каталоговых з

Размер блока
Если принято решение хранить файл в блоках, то возникает вопрос о размере этих блоков. Есть две крайности: · Большие блоки - например, 1Мбайт, то файл даже 1 байт займет целый бло

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

Дисковые квоты
Чтобы ограничить пользователя, существует механизм квот. Два вида лимитов: · Жесткие - превышены быть не могут · Гибкие - могут быть превышены, но при выходе пользователь

Резервное копирование
Случаи, для которых необходимо резервное копирование: · Аварийные ситуации, приводящие к потере данных на диске · Случайное удаление или программная порча файлов Основные

Непротиворечивость файловой системы
Если в системе произойдет сбой, прежде чем модифицированный блок будет записан, файловая система может попасть в противоречивое состояние. Особенно если это блок i-узла, каталога и

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

Файловая система ISO 9660
Более подробная информация - http://ru.wikipedia.org/wiki/ISO_9660 Стандарт принят в 1988 г. По стандарту диски могут быть разбиты на логические разделы, но мы будем рассматривать диски с

Каталоговая запись стандарта ISO 9660
Расположение файла - номер начального блока, т.к. блоки располагаются последовательно. L - длина имени файла в байтах Имя файла - 8 символов, 3 символа расширения (из-за совместим

Рок-ридж расширения для UNIX
Это расширение было создано, чтобы файловая система UNIX была представлена на CD-ROM. Для этого используется поле System use. Расширения содержат следующие поля: 1. PX -

Файловая система UDF (Universal Disk Format)
Более подробная информация - http://ru.wikipedia.org/wiki/Universal_Disk_Format Изначально созданная для DVD, с версии 1.50 добавили поддержку CD-RW и CD-R. Сейчас последняя верси

Файловая система MS-DOS (FAT-12,16,32)
В первых версиях был только один каталог (MS-DOS 1.0). С версии MS-DOS 2.0 применили иерархическую структуру. Каталоговые записи, фиксированны по 32 байта. Имена файлов -

Они будут задействованы в Windows 98
Атрибут архивныйнужен для программ резервного копирования, по нему они определяют надо копировать файл или нет. Поле время (16 разрядов) разбивается на три подполя:

Расширение Windows 98 для FAT-32
Для расширения были задействованы 10 свободных бит. Форм

Основная надстройка над FAT-32, это длинные имена файлов
Для каждого файла стали присваивать два имени: 1. Короткое 8+3 для совместимости с MS-DOS 2. Длинное имя файла, в формате Unicode Доступ к файлу может быть получен по люб

Формат каталогов записи с фрагментом длинного имени файла в Windows 98
Поле "Атрибуты" позволяет отличить фрагмент длинного имени (значение 0х0F) от дескриптора файла. Старые программы MS-DOS каталоговые записи со значением поля атрибутов 0х0

Файловая система NTFS
Файловая система NTFS была разработана для Windows NT. Особенности: · 64-разрядные адреса, т.е. теоретически может поддерживать 264*216 байт (1 208 925 819 M

Поиск файла по имени
При создании файла, программа обращается к библиотечной процедуре CreateFile("C:windowsreadmy.txt", ...) Этот вызов попадает в совместно используемую библиотеку уровня п

Сжатие файлов
Если файл помечен как сжатый, то система автоматически сжимает при записи, а при чтении происходит декомпрессия. Алгоритм работы: 1. Берутся для изучения первые 16 блоков файла (н

Шифрование файлов
Любую информацию, если она не зашифрована, можно прочитать, получив доступ. Поэтому самая надежная защита информации от несанкционированного доступа - шифрование. Даже если у вас украдут в

Файловая система UNIX V7
Хотя это старая файловая система основные элементы используются и современных UNIX системах. Особенности: · Имена файлов ограничены 14 символами ASCII, кроме косой черты "/&q

Структура i-узела
Поле Байты Описание Mode Тип файла, биты защиты, биты setuid и setgid Nlinks

Создание и работа с файлом
fd=creat("abc", mode) - Пример создания файла abc с режимом защиты, указанном в переменной mode(какие пользователи имеют доступ). Используется системный

Файловая система BSD
Основу составляет классическая файловая система UNIX. Особенности (отличие от предыдущей системы): · Увеличена длина имени файла до 255 символов · Реорганизованы каталоги

Размещение файловой системы EXT2 на диске
Другие особенности: · Размер блока 1 Кбайт · Размер каждого i-узла 128 байт. · i-узел содержит 12 прямых и 3 косвенных адресов, длина адреса в i-узле стала 4 байта, что о

Файловая система EXT3
В отличие от EXT2, EXT3 является журналируемой файловой системой, т.е. не попадет в противоречивое состояние после сбоев. Но она полностью совместима с EXT2.

Файловая система XFS
XFS - журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source). Официальная информация на http://oss.sgi.com/projec

Файловая система RFS
RFS (RaiserFS)- журналируемая файловая система разработанная Namesys. Официальная информация на RaiserFS Некоторые особенности: · Более эффективно работа

Файловая система JFS
JFS (Journaled File System) -журналируемая файловая система разработанная IBM для ОС AIX, но сейчас выпущенная как открытый код. Официальная информация на Journaled File S

Структура уровней файловой системы NFS
VFS (Virtual File System) - виртуальная файловая система. Необходима для управления таблицей открытых файлов. Записи для каждого открытого файла называются v-узлам

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

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

Способы реализации прикладных программных сред

В зависимости от архитектуры:

1. Прикладная программная среда в виде приложения (верхний слой ядра родной ОС).

Пользовательский режим работы, трансляция системных вызовов (вызовов API) в вызовы «родной» ОС. Соответствует классическим многослойным ОС (Unix, Windows).

2. Наличие нескольких прикладных сред, функционирующих равноправно. Каждая в виде отдельного слоя ядра.

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

3. Микроядерный принцип.

Любая прикладная среда оформляется в виде отдельного сервера пользовательского режима. Приложения, используя API, обращаются системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос и через микроядро возвращает результат. Могул использоваться функции микроядра. Возможно многократное обращение к другим ресурсам (во время работы микроядра).

Интерфейсы ОС

Интерфейс ОС – это прикладная система программирования. Регламентируется с помощью стандартов (POSIX, ISO).

1. Пользовательский интерфейс – реализуется с помощью специальных программных модулей, которые транслируют запросы пользователя на специальном командном языке в запросы к ОС.

Совокупность таких модулей называется интерпретатором . Он выполняет лексический и синтаксический анализ и либо сам выполняет команду, либо передает ее API.

2. API – предназначен для предоставления прикладным программам ресурсов ОС и реализации других функций. API описывает совокупность функций, процедур, принадлежащих ядру и надстройкам ОС. API использует системные программы как в составе ОС, так и за ее пределами, используя прикладные программы посредством среды программирования.

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

Интерфейсы ОС Linux:

· программный (без посредников – собственно выполнение системных вызовов);

· командной строки (посредник – оболочка интерпретатора Shell, перенаправляющая вызов);

· графический (посредники – Shell + графическая оболочка).

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

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

По составу ФС:

· совокупность всех файлов на диске на всех носителях,

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

· комплекс системных программных средств, реализующих управление файлами, в частности: создание, уничтожение, чтение, запись, именование, поиск и другие операции над файлами.

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

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

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

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

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

Вид возможной совместимости зависит от многих факторов. Самый главный из них – архитектура процессора. Если процессор применяет тот же набор команд (возможно, с добавлениями, как в случае IBM PC : стандартный набор + мультимедиа + графика + потоковые) и тот же диапазон адресов, то двоичная совместимость может быть достигнута достаточно просто. Для этого необходимо соблюдение следующих условий:

• API, который использует приложение, должен поддерживаться данной ОС;
• внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной ОС.

Если процессоры имеют разную архитектуру, то, кроме перечисленных условий, необходимо организовать эмуляцию двоичного кода. Например, широко используется эмуляция команд процессора Intel на процессоре Motorola 680x0 компьютера Macintosh. Программный эмулятор в этом случае последовательно выбирает двоичную инструкцию процессора Intel и выполняет эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как у процессора Motorola нет в точности таких же регистров, флагов, внутреннего АЛУ и др., как в процессорах Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти.

Это простая, но очень медленная работа, поскольку одна команда Intel выполняется значительно быстрее, чем эмулирующая ее последовательность команд процессора Motorola. Выходом в таких случаях является применение так называемых прикладных программных сред или операционных сред. Одной из составляющих такой среды является набор функций интерфейса прикладного программирования API , который ОС предоставляет своим приложениям. Для сокращения времени на выполнение чужих программ прикладные среды имитируют обращение к библиотечным функциям.

Эффективность этого подхода связана с тем, что большинство сегодняшних программ работает под управлением GUI (графических интерфейсов пользователя) типа Windows , MAC или UNIX Motif , при этом приложения тратят 60-80% времени на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программ. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие библиотеки GUI , но написанные на "родном" коде. Таким образом, достигается существенное ускорение выполнения программ с API другой операционной системы. Иначе такой подход называют трансляцией – для того, чтобы отличить его от более медленного процесса эмулирования по одной команде за раз.

Например, для Windows -программы, работающей на Macintosh, при интерпретации команд процессора Intel производительность может быть очень низкой. Но когда производится вызов функции GUI , открытие окна и др., модуль ОС, реализующий прикладную среду Windows , может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а, возможно, и превзойти) скорость работы на своём родном процессоре.

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

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

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

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

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

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микро ядерной архитектуры, в частности:

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

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

1.9. Виртуальные машины как современный подход к реализации множественных прикладных сред

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

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

Сегодня МВМ – снова в центре внимания. Корпорации Intel, AMD , Sun Microsystems и IBM создают стратегии виртуализации, в научных лабораториях и университетах для решения проблем мобильности, обеспечения безопасности и управляемости развиваются подходы, основанные на виртуальных машинах. Что же произошло между отставкой МВМ и их возрождением?

В 90-е годы исследователи из Стэндфордского университета начали изучать возможность применения ВМ для преодоления ограничений оборудования и операционных систем. Проблемы возникли у компьютеров с массовой параллельной обработкой (Massively Parallel Processing , MPP ), которые плохо поддавались программированию и не могли выполнять имеющиеся ОС. Исследователи обнаружили, что с помощью виртуальных машин можно сделать эту неудобную архитектуру достаточно похожей на существующие платформы, чтобы использовать преимущества готовых ОС. Из этого проекта вышли люди и идеи, ставшие золотым фондом компании VMware (www.vmware. com ), первого поставщика МВМ для компьютеров массового применения.

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

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

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

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

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

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

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

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

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

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

Вместо того чтобы заниматься сложной переработкой кода гостевой операционной системы, можно внести некоторые изменения в основную операционную систему, изменив некоторые наиболее "мешающие" части ядра. Подобный подход называется паравиртуализацией . Ясно, что в этом случае адаптировать ядро ОС может только автор , и, например, Microsoft не проявляет желания адаптировать популярное ядро Windows 2000 к реалиям конкретных виртуальных машин.

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

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

Чтобы добиться высокой производительности и совместимости при виртуализации архитектуры x86 , компания VMware разработала новый метод виртуализации, который объединяет традиционное прямое выполнение с быстрой трансляцией двоичного кода "на лету". В большинстве современных ОС режимы работы процессора при выполнении обычных прикладных программ легко поддаются виртуализации, а следовательно, их можно виртуализировать посредством прямого выполнения. Непригодные для виртуализации привилегированные режимы может выполнять транслятор двоичного кода, исправляя "неудобные" команды x86 . В результате получается высокопроизводительная виртуальная машина , которая полностью соответствует оборудованию и поддерживает полную совместимость ПО .

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

Хотя трансляция двоичного кода требует некоторых дополнительных расходов, при нормальных рабочих нагрузках они незначительны. Транслятор обрабатывает лишь часть кода, и скорость выполнения программ становится сопоставимой со скоростью прямого выполнения – как только заполнится кэш-

Совместимость и множественные прикладные среды

Концепция множественных прикладных сред связана с нуждами конечных пользователей - возможностью операционной системы выполнять приложения других операционных систем. Такое свойство операционной системы называется совместимостью .

Двоичная совместимость и совместимость исходных текстов

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

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

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

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

Вызовы функций API, которые содержит приложение, должны поддерживаться ОС;

Внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов ОС.

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

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

Один из наиболее очевидных вариантов реализации множественных прикладных сред основывается на стандартной многоуровневой структуре ОС и обеспечивает трансляцию системных вызовов.

На рисунке 6 операционная система OS1 поддерживает кроме своих приложений приложения операционных систем OS2 и OS3.

Для этого в ее составе имеются специальные приложения - прикладные программные среды, - которые транслируют интерфейсы «чужих» операционных систем API OS2 и API OS3 в интерфейс своей операционной системы - API OS1.

Рисунок 6 - Прикладные программные среды, транслирующие системные вызовы

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных программных интерфейсов (рисунок 7). В приведенном примере операционная система поддерживает приложения для OS1, OS2 и OS3.

Для этого непосредственно в пространстве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3.

Рисунок 7 - Реализация совместимости на основе нескольких равноправных API

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

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

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

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

Надежность и стабильность выражаются в том, что при отказе одной из прикладных сред все остальные сохраняют работоспособность;

Низкая производительность микроядерных ОС сказывается на скорости работы прикладных сред, а значит, и на скорости выполнения приложений.

Рисунок 8 - Микроядерный подход к реализации множественных прикладных сред

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