Методи за внедряване на приложни софтуерни среди. Приложен софтуер Начини за внедряване на приложен софтуер

16.08.2020

Прочетете също

Как да направите фабрично нулиране на Android?

Навигационни системи GPS, Glonass, Beidou, Galileo Какво е навигационна система beidou

Зареждането напуска телефона, какво да правя?

Защо батерията се изтощава бързо на телефон с Android

Какво да направите, ако батерията се изтощи бързо?

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

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

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

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

Видът на възможната съвместимост зависи от много фактори. Най-важната от тях е архитектурата на процесора. Ако процесорът използва същия набор от инструкции (може би с допълнения, както в случая на IBM PC: стандартен набор + мултимедия + графика + стрийминг) и същия адресен диапазон, тогава бинарната съвместимост може да бъде постигната съвсем лесно. За целта трябва да бъдат изпълнени следните условия:

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

вътрешната структура на изпълнимия файл на приложението трябва да съответства на структурата на изпълнимите файлове на ОС.

Ако процесорите имат различни архитектури, тогава в допълнение към горните условия е необходимо да се организира емулация на двоичния код. Например широко се използва емулация на процесорни инструкции на Intel на процесора Motorola 680x0 на Macintosh. Софтуерният емулатор в този случай последователно избира двоичната инструкция Процесор Intelи изпълнява еквивалентната подпрограма, написана в инструкциите на процесора на Motorola. Тъй като процесорът на Motorola няма точно същите регистри, флагове, вътрешно ALU и т.н. като процесорите на Intel, той трябва също да симулира (емулира) всички тези елементи, използвайки собствените си регистри или памет.

Това е просто, но много бавна работа, тъй като една инструкция на Intel се изпълнява много по-бързо от последователността от инструкции на процесора на Motorola, който я емулира. Изходът в такива случаи е използването на така наречените приложни софтуерни среди или операционни среди. Един от компонентите на такава среда е набор от функции на интерфейса на приложението. API програмиране, които ОС предоставя на своите приложения. За да се намали времето за изпълнение на програмите на други хора, приложните среди имитират извиквания на библиотечни функции.

Ефективността на този подход се дължи на факта, че повечето от съвременните програми работят под контрола на GUI (графични потребителски интерфейси) Тип Windows, MAC или UNIX Motif, като приложенията прекарват 60-80% от времето си в извършване на GUI функции и други извиквания на библиотека на OS. Именно това свойство на приложенията позволява на средите на приложенията да компенсират голямото време, изразходвано за емулация команда по команда на програми. Внимателно проектираната среда за софтуерни приложения включва библиотеки, които имитират GUI библиотеки, но написани в "роден" код. Така се постига значително ускоряване на изпълнението на програми с API на друга операционна система. Иначе този подход се нарича транслация - за да се разграничи от по-бавния процес на емулиране на една инструкция в даден момент.

Например за Windows програма, работеща на Macintosh, при интерпретиране на команди на процесора Производителност на Intelможе да е много ниско. Но когато се извика GUI функция, се отваря прозорец и т.н., OS модулът, който изпълнява приложението Windows среда, може да прихване това повикване и да го пренасочи към прекомпилиран за процесора Motorola 680x0, за да отвори прозорец. В резултат на това в такива части от кода скоростта на програмата може да достигне (и евентуално да надмине) скоростта на работа на собствения процесор.

За да може програма, написана за една операционна система, да работи на друга операционна система, не е достатъчно само да се осигури съвместимост с API. Концепциите, залегнали в основата на различните операционни системи, може да са в конфликт помежду си. Например, в една ОС на приложение може да бъде разрешено да контролира I / O устройства, в друга тези действия са прерогатив на ОС.

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

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

На ориз. 1.9 OS1 поддържа, в допълнение към своите "родни" приложения, приложения на операционни системи OS2 и OS3. За това съдържа специални приложения, среди за програмиране на приложения, които превеждат интерфейсите на "чужди" операционни системи API OS2 и API OS3 в интерфейса на тяхната "родна" ОС - API OS1. Така, например, ако OS2 беше UNIX OS, а 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. В примера операционната система поддържа приложения, написани за OS1, OS2 и OS3. За да направите това, интерфейсите за приложно програмиране на всички тези операционни системи се поставят директно в пространството на ядрото на системата: API OS1, API OS2 и API OS3.

Ориз. 3. 9. Осъществяване на съвместимост на базата на няколко
партньорски API

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

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

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

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

Този подход за проектиране на среди с множество приложения има всички предимства и недостатъци на микроядрената архитектура, по-специално:

Добавянето и изключването на приложни среди е много лесно, което е следствие от добрата разширяемост на микроядрените операционни системи;

Надеждността и стабилността се изразяват в това, че ако една от приложните среди откаже, всички останали остават работещи;

· ниската производителност на микроядрените операционни системи влияе върху скоростта на приложните среди, а оттам и върху скоростта на изпълнение на приложенията.

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

Въпроси за самопроверка

Какво се има предвид под архитектура на ОС?
Кои са трите основни слоя в структурата на една компютърна система?
Каква е ролята, възложена от операционната система на интерфейса за системни повиквания?
Какви условия трябва да бъдат изпълнени при проектирането на ОС, за да може ОС да бъде лесно преносима?
Каква е разликата между микроядрената архитектура и традиционната OS архитектура?
Защо микроядрото е подходящо за поддръжка на разпределени изчисления?
Какво се разбира под концепцията за среди с множество приложения?
Каква е същността на метода за превод на библиотека?

Край на работата -

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

Операционна система, процеси, хардуер

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

Ако имате нужда от допълнителен материал по тази тема или не сте намерили това, което търсите, препоръчваме да използвате търсенето в нашата база данни с произведения:

Какво ще правим с получения материал:

Ако този материал се оказа полезен за вас, можете да го запазите на страницата си в социалните мрежи:

Всички теми в този раздел:

Характеристики на хардуерните платформи
Свойствата на операционната система се влияят пряко от хардуера, към който е ориентирана. Операционните системи се класифицират по тип хардуер. персонални компютри, ми

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

Архитектура на операционната система
Всяка добре организирана сложна система има ясна и рационална структура, тоест тя е разделена на части - модули, които имат напълно завършено функционално предназначение с

Управление на основната памет
Паметта е голям масив от думи или байтове, всяка със собствен адрес. Това е склад за данни, на който се предоставя бърз достъпразпределени между процесора и

Управление на външна памет
Тъй като основната памет (първичната памет) е променлива и твърде малка, за да съхранява постоянно всички данни и програми, VS трябва да осигури вторична памет, за да запази основната памет. Бол

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

Работа в мрежа
Разпределена система - набор от процесори, които не разпределят памет или всеки процесор има собствена локална памет. Процесорите в системата са свързани чрез компютърна мрежаи осигуряване

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

Ядро и привилегирован режим
За да контролира надеждно изпълнението на приложенията, операционната система трябва да има определени привилегии над приложенията. В противен случай неправилно работещо приложение може

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

Основна структура
Хардуерна поддръжка на ОС. Досега за операционната система се говори като за набор от програми, но някои от функциите на ОС могат да се изпълняват и хардуерно. поет

Хардуерна зависимост и преносимост на ОС
Много операционни системи успешно работят на различни хардуерни платформи без значителни промени в техния състав. Това до голяма степен се дължи на факта, че въпреки разликите

Преносимост на операционната система
Ако кодът на операционната система може да бъде пренесен относително лесно от един тип процесор към друг тип процесор и от един тип хардуерна платформа към хардуерна платформа

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

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

Превод на библиотеки
Изходът в такива случаи е използването на т.нар приложни програмисреди. Един от компонентите, които формират средата на приложния софтуер, е набор от функ

Концепция на процеса
Процесът е дейност, която се изпълнява на процесор. В най-широк смисъл, процесор е всяко устройство в компютър, което

Концепция за ресурс
Една от функциите на ОС е да осигури ефективен и безконфликтен начин за управление на ресурсите на изчислителната система. Ресурсът често се разбира като индикатор

Концепцията за виртуализация
Виртуализацията на този или онзи ресурс се извършва в рамките на централизирана схема за разпределение на ресурсите. Чрез виртуализацията се прилагат две форми на измама на потребителите:

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

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

Концепция на процеса
Процес (задача) е програма, която е в режим на изпълнение. Всеки процес има собствено адресно пространство, свързано с него, от което може да чете и

Модел на процеса
В многозадачна система реалният процесор превключва от процес на процес, но за да се опрости моделът, се разглежда набор от процеси, работещи паралелно (псевдопаралелно). Обмисли

Прекратяване на процес
(изход от повикване или ExitProcess): Планирано прекратяване (край на изпълнение) Планирано излизане при известна грешка (напр. липсващ файл)

Йерархия на процеса
UNIX системите имат твърда йерархия на процесите. Всеки нов процес, създаден от системното извикване на fork, е дете на предишния процес. Дъщерният процес получава от родителския процес

Състояние на процеса
Трите състояния на един процес са: Изпълнение (заемане на процесора) Готовност (процесът е временно спрян, за да позволи на друг процес да се изпълнява) Изчакване (процесът

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

модел на потока
Всяка нишка е свързана с: Брояч на изпълнение на команда Регистри за текущи променливи Състояние на стека Нишките споделят елементи помежду си

Ползи от използването на нишки
Опростяване на програмата в някои случаи чрез използване на общо адресно пространство. Скоростта на създаване на нишка, в сравнение с процес, е около 100 пъти. Повишен

Внедряване на нишки в потребителско пространство, ядро и смесено
A - нишки в потребителското пространство B

Функции за внедряване на Windows
Използват се четири понятия: Job - набор от процеси с общи квоти и лимити Proces - контейнер с ресурси (памет...), съдържа поне една нишка. Пото

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

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

Състояние на състезанието
Състезание е ситуация, при която множество процеси четат или записват данни (в памет или файл) едновременно. Помислете за пример, при който два процеса се опитват да

Критични зони
Критичен регион е част от програма, която има достъп до споделени данни. Условия за избягване на спорове и ефективна работапроцеси: Два процеса не са

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

Строго редуване
В този модел процесите могат да се изпълняват строго последователно с помощта на променлива.

Примитиви за взаимодействие на процеси
Въвежда се концепцията за два примитивни елемента. sleep е системна заявка, която кара извикващия процес да блокира, докато не бъде стартиран от друг процес. уак

семафори
Семафорите са променливи за преброяване на задействащи сигнали, съхранени за бъдещето. Бяха предложени две операции надолу и нагоре (аналози на сън и събуждане

Планиране в системи за пакетна обработка
6.2.1 First In Fist Out (FIFO) Процесите се нареждат на опашка, когато пристигнат. Предимства:

Циклично планиране
Най-простият алгоритъм за планиране и често използван. На всеки процес се дава отрязък от време на процесора. Когато квантът приключи, процесът се прехвърля от планировчика към края на

Приоритетно планиране
На всеки процес се присвоява приоритет и управлението се прехвърля към процеса с най-висок приоритет. Приоритетът може да бъде динамичен или статичен. Динамика

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

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

Застой на процеса
Застой на процеса може да възникне, когато множество процеси се конкурират за един и същ ресурс. Ресурсите могат да бъдат странирани и нестраницирани, хардуерни и софтуерни.

Моделиране на безизходици
Моделиране на задънени улици с графики. КонвенцииНа такъв модел

Откриване и премахване на безизходица
Системата не се опитва да предотврати безизходицата, но се опитва да я открие и разреши. Откриване на блокиране, когато има по един ресурс от всеки тип

Избягване на динамично блокиране
По този начин операционната система трябва да знае дали предоставянето на ресурс е безопасно или не. Ресурсни траектории Да разгледаме модел на два процеса и два ресурса

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

I/O хардуерни принципи
Двете по-ниски нива на системата за управление на I / O са хардуерни: самите устройства, които директно извършват операции, и техните контролери, които служат за организиране съвместна работаустройство

Контролери на устройства
I/O устройствата обикновено се състоят от две части: механична (да не се разбира буквално) - диск, принтер, монитор, електронна - контролер или

I/O, картографиран в паметта
Всеки контролер има няколко регистъра, които се използват за взаимодействие с централния процесор. С помощта на тези регистри ОС управлява (чете, записва, включва и т.н.) и определя

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

Прекъсва
След като I/O устройството стартира, процесорът превключва към други задачи. За да сигнализира за края на процесора на процесора, устройството инициира прекъсване,

I/O софтуерни задачи
Основните задачи за решаване софтуер I/O: Независимост от устройството - например програма, която чете данни от файл, не трябва да мисли защо

Софтуер I/O
В този случай процесорът върши цялата работа. Помислете за процеса на отпечатване на низа ABCDEFGH по този начин.

I/O, управляван от прекъсване
Ако в предишния пример буферът не се използва и принтерът отпечатва 100 знака в секунда, тогава всеки знак ще отнеме 10 ms, през което време процесорът ще работи на празен ход, чакайки печатът да бъде готов.

Обработчици на прекъсвания
Прекъсванията трябва да бъдат скрити възможно най-дълбоко в недрата на операционната система, така че възможно най-малко операционна система да трябва да се справя с тях. Най-добре е да блокирате драйвера, който е стартирал I/O. Алго

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

Независим от устройството I/O софтуер
Независими от устройства I/O софтуерни функции: Единен интерфейс за драйвери на устройства, съобщения за грешка при буфериране

Обобщение на I/O нива и функции
Нива и основни функции на I/O системата Baz

Блокиращи, неблокиращи и асинхронни системни повиквания
Всички системни повиквания, свързани с изпълнението на I / O операции, могат да бъдат разделени на три групи според начините за осъществяване на взаимодействието между процеса и I / O устройството. към първия, към

Буфериране и кеширане
Буферът обикновено се разбира като някаква област от паметта за съхраняване на информация, когато се обменят данни между две устройства, два процеса или процес и устройство. Размяна в

Устройства за спулиране и прихващане
Говорихме за концепцията за спулинг в първата лекция от нашия курс, като механизъм, който за първи път направи възможно комбинирането на реални I / O операции на една задача с изпълнението на друга задача.

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

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

Принципи зад UNIX I/O подсистемата за управление
1. Тази подсистема е изградена по същия начин като подсистемата за управление на данни (файлова система). На потребителя се предоставя унифициран начин за достъп както до PU, така и до файловете. Под файл в ОС

Управление на паметта на ОС
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. · Парола - парола към fa

Файлове, свързани с адресното пространство на паметта
Понякога е удобно да картографирате файл в паметта (няма нужда да използвате I/O системни извиквания за работа с файла) и да работите с паметта и след това да запишете модифицирания файл на диска. При използване

Системи с директории на едно ниво
В тази система всички файлове се съдържат в една директория. од

Име на пътя
За да организирате дърво на директория, имате нужда от някакъв начин да посочите файл. Двата основни метода за указване на файл са: абсолютен път - указва пътя от корена

Внедряване на директория
Когато отваряте файл, името на пътя се използва за намиране на записа в директорията. Входът в директорията сочи към адресите на дисковите блокове. В зависимост от системата това може да бъде: ад на диска

Внедряване на дълги имена на файлове
По-ранните операционни системи използваха кратки имена на файлове, MS-DOS до 8 знака, в UNIX версия 7 до 14 знака. Сега се използват по-дълги имена на файлове (до 255 знака или повече).

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

A - споделен файл
Такава файлова система се нарича насочена ациклична графа (DAG, Directed Acyclic Graph). Има проблем, ако дисковите адреси се съдържат в самите записи в директорията.

Размер на блока
Ако се вземе решение файлът да се съхранява на блокове, тогава възниква въпросът за размера на тези блокове. Има две крайности: Големи блокове - например 1MB, тогава дори файл от 1 байт ще заеме цял блок

Отчитане на безплатни блокове
Има два основни начина за отчитане на безплатни блокове: · Свързан списък от дискови блокове, всеки блок съдържа толкова свободни номера на блокове, колкото пречи на блока. Често за резервния списък

Дискови квоти
За ограничаване на потребителя има квотен механизъм. Два вида ограничения: Твърди - не могат да бъдат превишени Гъвкави - могат да бъдат превишени, но когато потребителят излезе

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

Съгласуваност на файловата система
Ако системата се срине преди да бъде записан модифицираният блок, файловата система може да влезе в непоследователно състояние. Особено ако е блок i-node, блок директория и

кеширане
Блоков кеш (буферен кеш) - набор от блокове, съхранени в паметта, но логически принадлежащи на диска. Всички заявки за четене към диска се прихващат и наличието на изисква

ISO 9660 файлова система
Повече информация - http://en.wikipedia.org/wiki/ISO_9660 Стандартът е приет през 1988 г. Според стандарта дисковете могат да бъдат разделени на логически дялове, но ние ще разглеждаме дискове с

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

Разширения на Rock Ridge за UNIX
Това разширение е създадено, така че файловата система UNIX да присъства на CD-ROM. За целта се използва полето Използване на системата. Разширенията съдържат следните полета: 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
Полето "Атрибути" ви позволява да разграничите фрагмент от дълго име (стойност 0x0F) от файлов дескриптор. Стари записи в директория с програми на MS-DOS със стойност на полето на атрибута 0x0

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

Намиране на файл по име
Когато създава файл, програмата извиква библиотечната процедура CreateFile("C:windowsreadmy.txt", ...) Това извикване отива в споделената библиотека от ниво n

Компресиране на файлове
Ако файлът е маркиран като компресиран, системата автоматично компресира при запис и декомпресира при четене. Алгоритъм на работа: 1. Първите 16 блока от файла се вземат за изследване (n

Криптиране на файлове
Всяка информация, ако не е криптирана, може да бъде прочетена чрез получаване на достъп. Следователно най надеждна защитаинформация от неоторизиран достъп - криптиране. Дори да те крадат

Файлова система UNIX V7
Въпреки че е стара файлова система, основните елементи все още се използват от съвременните UNIX системи. Характеристики: Имената на файловете са ограничени до 14 ASCII знака, с изключение на наклонената черта "/&q"

i-node структура
Поле Байтове Описание Режим Тип файл, битове за сигурност, битове setuid и setgid Nlinks

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

BSD файлова система
Основата е класическата UNIX файлова система. Характеристики (различни от предишна система): Увеличена дължина на името на файла до 255 знака Реорганизирани директории

Местоположение на файловата система EXT2 на диска
Други характеристики: · Размер на блока 1 KB · Размерът на всеки i-node е 128 байта. I-node съдържа 12 директни и 3 индиректни адреса, дължината на адреса в i-node е станала 4 байта, което е около

EXT3 файлова система
За разлика от EXT2, EXT3 е журналираща файлова система, т.е. няма да изпадне в непоследователно състояние след неуспехи. Но е напълно съвместим с EXT2.

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

RFS файлова система
RFS (RaiserFS) е журналираща файлова система, разработена от Namesys. Официална информация за RaiserFS Някои функции: По-ефективна работа

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

Структура на нивата на файловата система NFS
VFS (Virtual File System) - виртуална файлова система. Необходим за управление на таблицата с отворени файлове. Вписвания за всички отворете файласе наричат v-възли

Алтернатива на емулация - среди с множество приложения, който включва набор от API функции. Те имитират извикването на библиотечните функции на приложната среда, но всъщност извикват своите вътрешни библиотеки. Нарича се библиотечен превод. Това е чисто софтуерно.

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

Начини за внедряване на приложни софтуерни среди

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

1. Приложна софтуерна среда под формата на приложение (горният слой на ядрото на родната ОС).

Персонализиран режим на работа, превод на системни извиквания (API повиквания) в собствени извиквания на OS. Съответства на класическа многослойна ОС (Unix, Windows).

2. Наличието на няколко приложни среди, които функционират еднакво. Всеки под формата на отделен слой от ядрото.

Привилегирован режим на работа. API извиква функциите на основния (привилегирован) слой на операционната система. Задачата за разпознаване и адаптиране на обаждането пада върху системата. Задължително голям бройресурси. Набор от идентифициращи характеристики се предава на ядрото за разпознаване.

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

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

OS интерфейси

OS интерфейсе система за програмиране на приложения. Регулирани от стандарти (POSIX, ISO).

1. Потребителски интерфейс- изпълнява се с помощта на спец софтуерни модули, които превеждат потребителски заявки на специален команден език в заявки към операционната система.

Наборът от такива модули се нарича преводач. Той извършва лексикален анализ и анализ и или изпълнява самата команда, или я предава на API.

2. API- е предназначен да предостави на приложните програми ресурси на ОС и да реализира други функции. API описва набор от функции, процедури, които принадлежат на ядрото и добавките на ОС. API използва системни програмикакто в рамките на ОС, така и извън нея, използвайки приложни програми през средата за програмиране.

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

Интерфейси на Linux OS:

софтуер (без посредници - самото изпълнение на системните повиквания);

· командна линия(посредник - обвивка на интерпретатора на Shell, която пренасочва повикването);

Графичен (посредници - Shell + графичен шел).

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

Файлова система е част от операционната система, предназначена да предостави на потребителите удобен за потребителя интерфейсработа с файлове и осигуряване на използването на файлове, съхранявани на външен носител ( HDD+ RAM) от множество потребители и процеси.

Според състава на ФС:

съвкупността от всички файлове на диска на всички носители,

набори от структури от данни, използвани за управление на файлове, като файлови директории, файлови дескриптори, таблици за разпределение на свободно и използвано дисково пространство,

комплекс от системни софтуерни инструментикоито изпълняват управление на файлове, по-специално: създаване, унищожаване, четене, запис, именуване, търсене и други операции върху файлове.

Един от атрибутите на файловете са имената на файловете, начин за идентифициране на файл за потребителя. В тези системи, където са разрешени множество имена, на файла се присвоява inode, използван от ядрото на ОС. Имената в различните операционни системи се задават по различен начин.

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

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

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

API, който приложението използва, трябва да се поддържа от дадената ОС;
вътрешната структура на изпълнимия файл на приложението трябва да съответства на структурата на изпълнимите файлове на ОС.

Ако процесорите имат различни архитектури, тогава в допълнение към горните условия е необходимо да се организира емулация на двоичния код. Например широко се използва емулация на процесорни инструкции на Intel на процесора Motorola 680x0 на Macintosh. Софтуерният емулатор в този случай последователно избира двоичната инструкция на процесора на Intel и изпълнява еквивалентната подпрограма, написана в инструкциите на процесора на Motorola. Тъй като процесорът на Motorola няма точно същите регистри, флагове, вътрешно ALU и т.н., както в процесорите на Intel, той трябва също да симулира (емулира) всички тези елементи, използвайки собствените си регистри или памет.

Това е проста, но много бавна операция, тъй като една инструкция на Intel е много по-бърза от последователността от инструкции на Motorola, която я емулира. Изходът в такива случаи е използването на така наречените приложни софтуерни среди или операционни среди. Един от компонентите на такава среда е API наборът от функции, които операционната система излага на своите приложения. За да се намали времето за изпълнение на програмите на други хора, приложните среди имитират извиквания на библиотечни функции.

Ефективността на този подход се дължи на факта, че повечето от днешните програми работят под GUI (графични потребителски интерфейси) като Windows, MAC или UNIX Motif, докато приложенията прекарват 60-80% от времето, изпълнявайки GUI функции и други извиквания на библиотеката на OS . Именно това свойство на приложенията позволява на средите на приложенията да компенсират голямото време, изразходвано за емулация команда по команда на програми. Внимателно проектираната среда на софтуерно приложение съдържа библиотеки, които имитират GUI библиотеки, но написани в естествен код. Така се постига значително ускоряване на изпълнението на програми с API на друга операционна система. Иначе този подход се нарича транслация - за да се разграничи от по-бавния процес на емулиране на една инструкция в даден момент.

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

За да може програма, написана за една ОС, да работи на друга ОС, не е достатъчно само да се осигури съвместимост с API. Концепциите, залегнали в основата на различните операционни системи, може да са в конфликт помежду си. Например, в една ОС на приложение може да бъде разрешено да контролира I / O устройства, в друга тези действия са прерогатив на ОС.

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

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

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

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

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

1.9. Виртуалните машини като съвременен подход за внедряване на среди с множество приложения

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

През 80-те и 90-те години цената спадна значително. компютърно оборудванеи ефективен многозадачна ОС, което намали стойността на VMM в очите на потребителите. Мейнфреймите отстъпиха място на миникомпютрите, а след това на компютрите и необходимостта от VMM изчезна. В резултат на това компютърната архитектура просто изчезна хардуерза ефективното им прилагане. До края на 80-те години в науката и в производството на ВММ те се възприемат само като историческо любопитство.

Днес MVM отново е в светлината на прожекторите. Intel, AMD, Sun Microsystems и IBM създават стратегии за виртуализация, а лаборатории и университети разработват базирани на виртуални машини подходи за справяне с проблемите на мобилността, сигурността и управляемостта. Какво се случи между оставката на MVM и тяхното съживяване?

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

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

За да намалите въздействието на системните сривове и да защитите от хакове, системни администраторивърна се към еднозадачност изчислителен модел(с едно приложение на една машина). Това доведе до допълнителни разходи поради увеличените хардуерни изисквания. Преместването на приложения от различни физически машини към виртуални машини и консолидирането на тези виртуални машини на няколко физически платформи подобри използването на хардуера, намали разходите за управление и намали пространството. Така че способността на VMM да мултиплексира хардуер – този път в името на консолидацията на сървъра и помощните изчисления – ги върна към живота.

В момента VMM се е превърнал не толкова в инструмент за организиране на многозадачност, както някога е бил замислен, а в решение на проблемите с осигуряването на сигурност, мобилност и надеждност. В много отношения VMM дава възможност на разработчиците на операционни системи да развиват функционалност, която не е възможна с днешните сложни операционни системи. Функции като миграция и защита са много по-удобни за изпълнение на ниво VMM, което поддържа обратна съвместимост при внедряване на иновативни решения за операционна система, като същевременно запазва предишни постижения.

Виртуализацията е развиваща се технология. Най-общо казано, виртуализацията ви позволява да отделите софтуера от основната хардуерна инфраструктура. Всъщност той прекъсва връзката между определен набор от програми и конкретен компютър. Мониторът на виртуалната машина се отделя софтуерот хардуера и формира междинно ниво между работещия софтуер виртуални машини, и хардуер. Това ниво позволява на VMM да контролира напълно използването на хардуерни ресурси. операционни системи за гости (GuestOS)които се изпълняват на VM.

VMM създава унифициран изглед на основния хардуер, така че физическите машини от различни доставчици с различни I/O подсистеми да изглеждат еднакво и VM да работи на всеки наличен хардуер. Като не се интересуват от отделните машини с техните тесни хардуерно-софтуерни взаимовръзки, администраторите могат просто да гледат на хардуера като на набор от ресурси, за да предоставят всякакви услуги при поискване.

Благодарение на пълно капсулиранесофтуерни състояния на VM, мониторът на VMM може да картографира VM към всички налични хардуерни ресурси и дори да го премести от една физическа машина на друга. Задачата за балансиране на натоварването в група машини става тривиална и има надеждни начини за справяне с хардуерни повреди и разрастване на системата. Ако трябва да изключите повреден компютър или да върнете нов онлайн, VMM е в състояние да преразпредели виртуалните машини по съответния начин. Виртуалната машина е лесна за копиране, което позволява на администраторите бързо да предоставят нови услуги, ако е необходимо.

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

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

Пълната изолация също е важна за надеждността и безопасността. Приложенията, които преди са работили на една машина, сега могат да бъдат разпределени между различни виртуални машини. Ако едно от тях причини срив на операционната система в резултат на грешка, други приложения ще бъдат изолирани от него и ще продължат да работят. Ако едно от приложенията е застрашено от външна атака, атаката ще бъде локализирана в рамките на „компрометираната“ VM. По този начин VMM е инструмент за преструктуриране на системата за подобряване на нейната стабилност и сигурност, без да изисква допълнително пространство и административни усилия, които са необходими при стартиране на приложения на отделни физически машини.

VMM трябва да асоциира хардуерен интерфейс с VM, като същевременно запазва пълен контрол над базова машинаи процедури за взаимодействие с неговия хардуер. За постигането на тази цел има различни методи, базирани на определени технически компромиси. При търсенето на такива компромиси се вземат предвид основните изисквания към VMM: съвместимост, производителности простота. Съвместимостта е важна, тъй като основното предимство на VMM е способността да изпълнява наследени приложения. производителностопределя количеството режийни разходи за виртуализация - програмите на VM трябва да се изпълняват със същата скорост, както на реалната машина. Простотата е необходима, защото повредата на VMM ще доведе до повреда на всички VM, работещи на компютъра. По-специално, надеждната изолация изисква VMM да не съдържа грешки, които атакуващите могат да използват, за да унищожат системата.

Вместо да преминавате през сложно пренаписване на кода на гост операционната система, можете да направите някои промени в хост операционната система, като промените някои от най-"пречещите" части на ядрото. Този подход се нарича паравиртуализация. Ясно е, че в този случай само авторът може да адаптира ядрото на ОС и, например, Microsoft не показва никакво желание да адаптира популярното ядро на Windows 2000 към реалностите на конкретни виртуални машини.

При паравиртуализацията разработчикът на VMM предефинира интерфейса на виртуалната машина, като заменя подмножество от оригиналния набор от инструкции, който е неподходящ за виртуализация, с по-удобни и ефективни еквиваленти. Имайте предвид, че въпреки че операционната система трябва да бъде пренесена, за да работи на такива виртуални машини, повечето често срещани приложения могат да работят непроменени.

Най-големият недостатък на паравиртуализацията е несъвместимостта. Всякакви операционна система, проектиран да работи под контрола на паравиртуализиран VMM монитор, трябва да бъде пренесен към тази архитектура, за което е необходимо да се договори сътрудничество с доставчиците на ОС. Освен това наследените операционни системи не могат да се използват и съществуващите машини не могат лесно да бъдат заменени с виртуални.

За постигане на висока производителност и съвместимост при 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 - Подход на микроядро за внедряване на среди с множество приложения