10465

Настраиваемость операционных систем

Реферат

Информатика, кибернетика и программирование

Тема: Настраиваемость операционных систем. В последнее время одной из главных тем исследовательских работ в области операционных систем стало исследование настраиваемости customizability или адаптируемости операционной системы. Настраиваемой или адаптируемой операци

Русский

2013-03-26

69.04 KB

2 чел.

Тема: «Настраиваемость операционных систем».

В последнее время одной из главных тем исследовательских работ в области операционных систем стало исследование настраиваемости (customizability) или адаптируемости операционной системы. Настраиваемой или адаптируемой операционной системой называется операционная система, допускающая гибкую модификацию основных механизмов, стратегий и политик системы. В зависимости от контекста, настраиваемость системы может преследовать различные цели. В операционных системах общего назначения, как правило, такой целью является производительность системы в целом. Для встроенных систем настраиваемость служит целям энергосбережения и/или сокращения объема программного обеспечения. В ранних ОС присутствовала некая форма настройки; чаще всего она заключалась в возможности настраивать систему на этапе ее генерации. Однако в последнее время появились исследования и других способов адаптации ОС – это касается инициатора настройки и времени ее осуществления. Инициатором адаптации может быть администратор или проектировщик ОС (т.е. человек), приложение или сама операционная система. В последнем случае адаптация называется автоматической. Что касается времени настройки, то она может роисходить на этапе проектирования, компоновки или инсталляции (статическая адаптация), а также во время загрузки и даже во время выполнения (динамическая адаптация).

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

При обсуждении настраиваемости ОС часто применяются понятия распространения (spread) и уровня детализации настройки.

1 Адаптация, осуществляемая человеком

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

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

1.1. Статическая адаптация, инициированная проектировщиком

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

Flux OSKit – это система, состоящая из каркаса и библиотечных модулей [FBB97]. Каркас OSKit представляет собой набор библиотек, из которых компонуется ядро ОС. Все компоненты состоят из модулей. Используются интегрирующие (glue) слои, через которые осуществляется взаимодействие между компонентами и сервисами. Вообще говоря, компоненты скорее обладают крупным уровнем детализации, и являются, в основном, подсистемами, такими как файловая система, стек сетевого протокола или набор драйверов устройств.

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

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

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

Choices – это объектно-ориентированная, настраиваемая ОС, в которой для настраиваемости используются каркасная технология и подсистемы [CRJ87, CIR93]. Основное предназначение Choices – обеспечить пользователям возможность простой оптимизации и адаптации системы в соответствии с поведением приложений и рабочей нагрузкой. Система Choices спроектирована как иерархия каркасов, поддерживающих удобную организацию операционной системы по слоям. В Choices каркас состоит из набора классов, представляющих системные сущности, такие как диски, память, планировщики и т.д. Различные подсистемы ОС, такие как управление памятью, управление процессами, файловое запоминающее устройство, управление исключительными ситуациями и т.д. создаются непосредственно из объектно-ориентированных каркасов. Ресурсы системы, механизмы и политики представляются как экземпляры классов, принадлежащих некоей иерархии классов, где настройка осуществляется через использование наследования. Таким образом, специфическая ОС создается путем конкретизации классов и реализации набора объектов, которые вместе формируют данную ОС. Интерфейсом приложения является совокупность объектов ядра, экспортируемых через уровень защиты приложение/ядро.

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

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

Система PURE (Portable Universal Runtime Executive) является хорошо конфигурируемой системой и предоставляет средства для подбора требуемой функциональности [Beu99]. Хотя применение PURE и не ограничено какой-либо областью приложений, все же ее главное предназначение находится в области глубоко встроенных систем. Проектирование PURE основано на двух концепциях – семейства программ и объектно-ориентированного подхода. Концепция семейства программ обеспечивает иерархическую структуру системы, в которой минимальный набор системных функций используется как платформа для реализационных или системных расширений. Объектно-ориентированный подход служит основой для реализации. Минимальным компонентом является класс, т.е. систему PURE можно рассматривать как библиотеку классов. Например, компонент, реализующий управление потоками, состоит из 45 классов, выстроенных в 14-уровневую иерархию.

Компоненты PURE упорядочиваются в структуру, состоящую из ядер и их расширений. Ядра, так называемые CORE (concurrent runtime executive), отвечают за реализацию минимального набора системных функций, управляющих прерываниями и потоками. Дополнительные возможности, называемые минимальными системными расширениями, добавляются в систему с помощью ядерных расширений, называемых NEXT (Nucleus Extension).

Система PURE хорошо конфигурируется и обладает высоким уровнем детализации настройки.

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

1.2. Динамическая адаптация, инициированная администратором

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

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

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

Динамическая адаптация от имени администратора широко применяется во всех промышленных ОС (Linux, Solaris, Windows NT и т.д.). Windows 2000 имеет сотни счетчиков производительности и соответствующих системных переменных. Ядро Linux интенсивно использует загружаемые модули.

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

2. Адаптация, инициированная приложением

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

2.1. Адаптация с уровня приложения

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

2.1.1 Микроядерные ОС

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

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

Выбранный набор абстракций, интегрированных в ядро, существенным образом влияет на производительность и гибкость. Чем меньше абстракций, тем большая гибкость остается для приложений. В ядре должны присутствовать только те абстракции, которые необходимы для деятельности самого ядра. Это хорошо сформулировано в работах Лидке [Lie95, Lie96] о системе L4 – в ней ядерными абстракциями являются адресные пространства, потоки, IPC и уникальные идентификаторы. На основе этих абстракциями в L4 поддерживается рекурсивная конструкция адресных пространств – исходное адресное пространство включает всю память и порты ввода/вывода и принадлежит исходной подсистеме или приложению.

Результатом приближения микроядерной философии к ее логической крайности становится ОС, в которой все системные сервисы выведены за пределы ядра и реализованы в виде библиотек, а само ядро представляет собой попросту абстракцию аппаратных ресурсов. Такой экстрим реализован в ОС Exokernel [EKO95]. В ядре Exokernel отсутствуют какие-либо абстракции ОС и весь его интерфейс сведен к надстройке над аппаратурой. Единственная функция, которая оставлена в Exokernel – это выделение, возврат и мультиплексирование физических ресурсов (страниц памяти, квантов времени процессора, блоков дисков и т.п.) безопасным образом. Композиция наиболее используемых интерфейсов в Exokernel до сих пор остается большой проблемой [SSF99].

К микроядерным ОС можно отнести систему 2K [2K]. Система 2K основана на компонентах, и ее основной задачей является обеспечение настраиваемого каркаса для поддержки адаптации в сетевом окружении. Способность к адаптации регулируется параметрами, такими как пропускная способность сети, связность, доступность памяти, протоколы взаимодействия и компоненты аппаратных средств. ОС 2K основывается на технологии Corba, и в ней для адаптации используются данные метауровня и методы, которые предлагает уровень ORB (object request broker). Компонент 2K – это динамически загружаемый программный модуль, который хранится в динамически подключаемой библиотеке (DLL). Следует отметить, что в системе 2K используется крупный уровень детализации.

2.1.2. Портал-ориентированные системы

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

Примером портал-ориентированной системы служит Kea  портал-ориентированное микроядро, которое обеспечивает низкоуровневые концепции для конструирования высокоуровневых сервисов [VH96]. Под низкоуровневыми концепциями понимаются домены (виртуальные адресные пространства), обращения доменов друг к другу (IPC) и порталы. Портал ассоциирован с определенным сервисом – это точка входа для обращения к домену. Каждый сервис обязан регистрировать в ядре свой идентификатор, а ядро управляет доступом к интерфейсу этого сервиса. В отличие от истинных микроядерных ОС Kea не дает полной свободы для проектирования и реализации сервисов. Но все же в Kea обеспечивается возможность динамической реконфигурации. При обращении к сервису (через его портал) ядро может решать, какую реализацию выбрать. Например, при использовании файлового сервиса администратор может наложить обязательный вызов сервиса сжатия данных перед передачей их файловому сервису. Более сложная реконфигурация возникает в случае, когда приложение ассоциирует новый портал с идентификатором некоторого сервиса. Например, при использовании менеджером виртуальной памяти портала для сервиса замещения страниц приложение может заставить его использовать для своих страниц собственный сервис замещения страниц. В Kea уровень детализации адаптации определяется реализацией сервисов. Если менеджер виртуальной памяти фиксирует политику замещения страниц (вместо использования для нее портала, как в примере), никто не может ее изменить, пока не заменит весь сервис.

В системе SPACE [PBK91] единственной абстракцией, присутствующей в ядре, является обобщение управления исключительными ситуациями, т.е. механизм управления прерываниями. Если бы такой обобщенный механизм управления исключительными ситуациями мог бы быть реализован на аппаратном уровне, операционную систему можно было бы считать “безъядерной”.

Система Pebble [MBG00], так же, как и SPACE, поддерживает взаимодействие через домены защиты, реализованное как обобщение управления прерываниями. Как и Kea, Pebble осуществляет взаимодействие доменов через порталы и допускает реконфигурацию порталов. Порталы реализуются как обобщенные обработчики прерываний. Ядро Pebble содержит только код, реализующий передачу потоков от одного домена защиты другому, и небольшое количество функций поддержки режима ядра. Как и Exokernel, Pebble отдает реализацию абстракций ресурсов на уровень пользователя, но, в отличие от Exokernel, Pebble обеспечивает совокупность высокоуровневых абстракций, которые реализуются компонентами пользовательского уровня, что упоминалось в разделе о статической адаптации, инициированной проектировщиком. Каждый компонент уровня пользователя выполняется в своем собственном домене защиты, изолированном аппаратными средствами защиты памяти.

2.1.3. Системы мандатов (Capability Systems)

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

Примечание. Инкапсуля́ция — свойство языка программирования, позволяющее объединить и защитить данные и код в объектe и скрыть реализацию объекта от пользователя (прикладного программиста). При этом пользователю предоставляется только спецификация (интерфейс) объекта.

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

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

Архитектура вложенных процессов системы Fluke сочетает микроядро с виртуальными машинами [FHL96]. Ядро обеспечивает базовые сервисы и интерфейс к ним. Виртуальные машины используют этот интерфейс и реэкспортируют его на следующий уровень. Каждый слой полностью симулирует среду для вышележащего уровня – интерфейс между слоями всегда один и тот же, что позволяет компоновать сервисы с помощью наложения (stacking) виртуальных машин. Благодаря такому наложению, или многоуровневому представлению Fluke поддерживает вертикальную декомпозицию сервисов, в то время как микроядро обеспечивает горизонтальную декомпозицию, перенося традиционную функциональность ядра на серверы пользовательского уровня, расположенные как бы рядом (side-by-side).

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

Система EROS (Extremely Reliable Operating System) состоит из ядра, которое реализует небольшой набор примитивных мандатных типов [SSF99]. Возможности, которые предлагает ядро EROS, относятся к довольно низкому уровню. Большинство системных функций реализуется приложениями уровня пользователя. Например, ядро EROS напрямую предоставляет страницы дисковой памяти, но не файловой системы. Файловая абстракция полностью строится на уровне приложений, и файловое приложение просто хранит содержимое файла в адресном пространстве, увеличивая адресное пространство по мере необходимости так, чтобы оно могло содержать весь файл. Обязанность файлового приложения состоит в том, чтобы реализовать такие операции, как чтение и запись, которые выполняются над файлом.

Такой метод проектирования – создание высокоуровневых функций за счет объединения базовых примитивов операционной системы в повторно используемые компоненты – основная стратегия для создания приложений EROS. Каждый экземпляр компонента реализуется с помощью отдельного процесса, а ядро обеспечивает высокопроизводительный механизм связи между процессами, позволяющий эффективно объединять эти компоненты. Фактически, крайне редко приложения EROS работают с предлагаемыми ядром объектами напрямую. Большинство приложений повторно использует компоненты, предоставляемые системой, или реализуют новые компоненты, которые обеспечивают необходимую функцию структурированным способом.

Приложения EROS структурируются как защищенные, связанные мандатами компоненты. Каждый экземпляр компонента работает с индивидуально указанными мандатами, определяющими его полномочия. Мандаты защищены ядром, как и объекты, на которые они указывают. Единственные операции, которые могут выполняться с мандатом – это операции, определяемые объектом. Благодаря этому сочетанию защиты и посредничества приложение, которое выполняет злоумышленный код, не может повредить систему в целом или нанести ущерб другим пользователям, а также не может использовать привилегии пользователя для того, чтобы повредить другие части пользовательской среды. Точно так же, мандаты управляют доступом к ресурсам, не позволяя злоумышленному коду злоупотреблять ресурсами или вывести остальную часть системы из работоспособного состояния.

2.1.4. Операционные системы с кэшированием

Cache Kernel – это ядро операционной системы V++ [CD94]. В этой системе приложения выполняются поверх ядер приложений, либо в том же самом, либо в другом адресном пространстве. Ядра приложений реализуют сервисы операционной системы. Они выполняются на уровне пользователя и обеспечивают загрузку и разгрузку объектов ОС (потоков, адресных пространств и других ядер приложений) в соответствии с их собственными политиками. Собственно ядро Cache Kernel функционирует как кэш для таких объектов. В его интерфейс включены операции для загрузки и разгрузки системных объектов. Для указания того, должен ли некоторый объект быть загружен или разгружен, используются сигналы.

2.1.5. Рефлективные операционные системы

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

MetaOS – это объектно-ориентированная ОС, основанная на использовании языка Java [HPM98]. Архитектура этой ОС состоит из трех уровней. Объекты приложений располагаются на базовом уровне. На уровне ниже находятся мета-объекты, динамически сгруппированные в мета-пространства. Каждое мета-пространство поддерживает ряд приложений с похожими требованиями. Этот уровень носит название мета-уровня. В самом низу находится мета-мета-уровень, который сжат до единственного мета-пространства – главного (master) мета-пространства. Это мета-пространство распределяет ресурсы согласно динамически замещаемой политике. В MetaOS используется открытая реализация для поддержки определения и конструирования объектов, мета-объектов и их интерфейсов. Через эти интерфейсы мета-пространства могут быть адаптированы и расширены динамическим и безопасным образом. Когда приложение начинает выполняться, оно выбирает наиболее подходящее доступное мета-пространство, в котором оно может инициировать ряд изменений с большим уровнем детализации. Если этого окажется недостаточно, приложение может клонировать мета-пространство и мигрировать в него. После этого приложение будет иметь полный контроль над мета-пространством и, таким образом, над собственной средой выполнения.

2.2. Адаптация на уровне ядра

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

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

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

Верификация гарантирует корректное поведение расширения до инсталляции и развертывания. При обсуждении ОС рассматриваются два вида верификации – верификация источника и верификация поведения.

При верификации источника код считается безопасным, если он введен в систему удостоверенной стороной (например, администратором). Такая практика применяется в промышленных ОС (UNIX, Windows NT), где такой подход носит название метода загружаемого модуля ядра. Загрузка модуля может выполняться как администратором, так и приложением с правами root, или даже приложениями с правами пользователя, которому разрешена такая загрузка, если он является удостоверенной третьей стороной (например, производитель данной ОС).

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

2.2.1. Программная защита

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

Программная локализация неисправностей.

Программная локализация неисправностей обеспечивает защиту памяти в едином адресном пространстве (например, внутри ядра). Она осуществляется в два этапа. Сначала ненадежный код загружается в собственный изолированный домен (так называемый “неисправный” домен), который является областью памяти, логически разделенной с ядром. Затем код модифицируется таким образом, что из него нельзя осуществить запись или выполнить команду перехода за пределы этого изолированного домена. Одним из способов реализации этого подхода является sandboxing (механизм обеспечения безопасности подкачанных из сети или полученных по электронной почте программ, предусматривающий изоляцию на время выполнения загружаемого кода в ограниченную среду – "песочницу"). Изолированный домен состоит из сегмента кода и сегмента данных. В старших битах адреса содержится идентификатор сегмента. Перед каждой ненадежной инструкцией в сегменте кода вставляются инструкции, которые записывают в старшие биты адреса в ненадежной инструкции идентификатор изолированного сегмента, не давая ей возможности обратиться по адресу за пределы этого домена. Взаимодействие между изолированными сегментами осуществляется через RPC-интерфейс (remote procedure calls).

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

  1. приложение может заменить реализацию метода некоторого объекта ядра (ресурса), если это разрешено, – это позволяет изменять стандартное поведение ресурсов,
  2. приложение может зарегистрировать в ядре обработчик некоего события, такого как подключение в сети к конкретному порту, что позволяет инсталлировать в ядре новые сервисы.

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

Безопасные языки.

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

Безопасные языки, широко используемые в исследовательских проектах, – это Modula-3, Java и ML. Язык ML имеет формальную типовую систему, известную как систему Hindley-Milner, и дает возможность осуществлять статическую проверку типов. Языки Modula-3 и Java обладают меньшим формализмом, поэтому, чтобы гарантировать в них политику безопасности, необходимо выполнять многочисленные проверки типов во время выполнения. Однако ML, как декларативный язык, обеспечивает недостаточную эффективность во время выполнения.

Система SPIN основана на языке Modula-3. Все взаимодействия между приложением и ядром осуществляются с помощью расширений. Каждое расширение связывается с событием. Расширение должно быть зарегистрировано диспетчером, который инсталлирует расширения и передает события расширениям. С отдельным событием может быть связано несколько расширений. Расширения замещаются или добавляются диспетчером. Modula-3, в основном, используется для гарантирования защиты памяти. Дополнительные ограничения накладываются диспетчером и стандартными расширениями. Динамический компоновщик гарантирует, что расширение видит только санкционированные события.

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

2.2.2. Автоматическая верификация

Метод автоматической верификации основан на представлении кода в определенном формате, называемом PCC (Proof-Carrying Code). PCC-модуль содержит формальное доказательство соответствия кода данной политике безопасности. Истинность доказательства гарантирует безопасность кода, и программный модуль может выполняться без проверок во время выполнения. Политика безопасности ядра описывается с помощью аксиом и правил вывода в доказательствах, а также формулируется в виде предикатов логики первого порядка для каждой инструкции, в которых указывается, при каких обстоятельствах выполнение каждой инструкции будет оставаться безопасным. Приложение использует предикаты политики безопасности для вычисления предиката безопасности. Затем доказывается безопасность этого предиката по правилам логики первого порядка с использованием аксиом и правил вывода политики безопасности. Доказательство присоединяется к расширению. Ядро, в свою очередь, также вычисляет предикат безопасности и проверяет истинность ассоциированного доказательства для этого предиката. Проверка достоверности может быть сделана через простую и эффективную проверку типов (type checking).

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

3. Автоматическая адаптация

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

Компиляция (программирование) — преобразование программой-компилятором исходного текста какой-либо программы, написанного на языке программирования высокого уровня, в язык, близкий к машинному, или в объектный код.

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

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

Система Synthetix предназначена для обеспечения специализированных реализаций сервисов операционной системы, генерируемых во время выполнения, на основании частичной оценки [CBK96]. Степень детализации и широта настраиваемости ограничены – проектировщик решает, какой сервис может быть конкретизирован и выбирает параметры конкретизации. Параметры сервиса вводятся с помощью инвариантов, с которыми связаны блоки защиты (guards). После проверки корректности параметров модуль сервиса замещается реализацией с новыми параметрами. Например, системный вызов открытия файла может возвращать конкретизированный код, обеспечивающий чтение файла. Такой код мог бы иметь инварианты, такие как размер блока на диске, последовательный доступ, монопольный доступ и т.п. Когда тот же самый файл позже открывается другим приложением, инвариант монопольного доступа становится некорректным из-за нарушения блока защиты, связанного с системным вызовом открытия файла.

Автоматический подход к настраиваемости исследовался в проекте VINO [SS97], который уже рассматривался выше, однако этот подход в VINO не был реализован. По мнению авторов для осуществления автоматической адаптации поведения системы необходимо получать сведения из следующих трех источников:

  1. периодическая статистика от каждой подсистемы VINO, 
  2. специализированный компилятор,
  3. трассы и журналы, которые регистрируют входящие запросы и произведенные результаты.

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

4. Сводные таблицы характеристик свойств ОСРВ

Ниже следуют 4 таблицы.


ОСРВ

Архитектура

Предсказуемая производительность реального времени

Что реализует микроядро, размер (мин., мах.)

VxWorks

Клиент-сервер, микроядро WIND Microkernel

Приоритетное планирование в двух вариантах, наследование приоритетов

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

QNX

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

Приоритетное планирование с выбором методов планирования. Наследование приоритетов

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

Windows CE

Модульная с ядром и необязательными компонентами

Приоритетное планирование

 

pSOS

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

Приоритетное планирование, отсутствует наследование приоритетов

 

ChorusOS

Многослойная

Приоритетное планирование, мъютексы реального времени, таймеры с высокой разрешающей способностью, MIPC

Многозадачность, поддержка акторов, управление потоками, управление LAP, управление исключительными ситуациями, минимальное управления прерываниями

OSE

Многослойная

Приоритетное планирование, механизм предотвращения инверсии приоритетов

Приоритетное планирование, асинхронная передача сообщений, управление памятью, размер – 6К, 80К

OS-9

 

Приоритетное планирование, механизм предотвращения инверсии приоритетов

размер – 128К, 4MB

C EXECUTIVE

 

 

размер – 5К, 22К

CMX-RTX

 

Приоритетное планирование, механизм предотвращения инверсии приоритетов

размер – 1К, 6К

Inferno

 

 

 

INTEGRITY

 

Приоритетное планирование, механизм предотвращения инверсии приоритетов

размер –70К

INtime

 

 

LynxOS

 

размер –280К, 4М

Nucleus

 

 

RTX

 

Приоритетное планирование, наследование приоритетов

 

CORTEX

 

 

DeltaOS

 

размер – 10К


ОСРВ

Распределенная обработка

Сетевые протоколы

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

VxWorks

 

TCP/IP, FTP, SMTP, NFS, PPP, RPC, Telnet, BSD 4.4 TCP/IP networking,IP, IGMP, CIDR, TCP, UDP, ARP, RIP v.1/v.2, Standard Berkeley sockets, zbufs, SLIP, CSLIP, BOOTP, DNS, DHCP, TFTP, NFS, ONC RPC, WindNet SNMP v.1/v.2c with MIB compiler - optional, WindNet OSPF

DOS-FS, NFS, TrueFFS

QNX

Прозрачный доступ к удаленным ресурсам. Упрощенное проектирование отказоустойчивых кластеров

TCP/IP, FTP, SMTP, SNMP, NFS, PPP, ATM, ISDN, RPC, Telnet, Bootp, tiny TCP/IP

RAM, Flash, QNX, Linux, DOS, CD-ROM, DVD, NFS, CIFS

Windows CE

 

 

 

PSOS

 

 

 

ChorusOS

Прозрачный доступ к удаленным ресурсам

IPv4, IPv6, PPP, NTP, BFP, DHCP NFS, RPC, LDAP, FTP, Telnet

UFS, FIFOFS, NFS, MSDOSFS, ISOFS, PROCFS, PDEVFS

OSE

Прозрачный доступ к удаленным ресурсам

TCP/IP, FTP, SMTP, SNMP, PPP, ATM, ISDN, X25, Telnet, Bootp, http-server, FTP/TFTP, NTP, various routing protocols

FAT, VFAT, FAT32

OS-9

 

TCP/IP, FTP, SMTP, SNMP, NFS, PPP, ATM, ISDN, X25, RPC, Telnet, Bootp, 802.11

 

C EXECUTIVE

 

TCP/IP, SNMP, PPP, SNMP

 

CMX-RTX

 

TCP/IP, FTP, SMTP, SNMP, NFS, PPP, Telnet, Bootp

 

Inferno

 

TCP/IP, FTP, PPP, Telnet, Bootp

 

INTEGRITY

 

TCP/IP, FTP, SMTP, SNMP, NFS, PPP, ATM, X25, RPC, Telnet, Bootp, http, pop3, IGMP, UDP, ARP, RIP, sockets, zero-copy stack, tftp

 

Intime

 

TCP/IP

 

LynxOS

 

TCP/IP, SNMP, NFS

 

Nucleus

 

TCP/IP, SMTP, SNMP, PPP, Telnet

 

RTX

 

TCP/IP, все протоколы, поддерживаемые в. Windows

 

CORTEX

 

TCP/IP

 

DeltaOS

 

TCP/IP, FTP, SMTP, PPP, WAP, HTTP, HTML, XML, OSPF2, RIP2, CORBA

 



ОСРВ

POSIX

Среда разработки

Целевые платформы

VxWorks

POSIX 1003.1, .1b, .1c (включая pThreads)

 

x86, PowerPC, ARM, MIPS, 68K, CPU 32, ColdFire, MCORE, Pentium, i960, SH, SPARC, NEC V8xx, M32 R/D, RAD6000, ST 20, TriCore

QNX

POSIX 1003.1-2001, с потоками и расширенным. РВ

Windows, Solaris, Self-Hosted, QNX4, Linux

ARM, MIPS, PowerPC, SH4, Strong ARM, XScale, x86

Windows CE

 

 

ARMV4, SH3, SH4, MIPS, X86

pSOS

 

 

 

ChorusOS

POSIX-сигналы, сигналы реального времени, потоки, таймеры, очереди сообщений, семафоры. сокеты, разделяемая память

 

UltraSPARC II (CP1500 и CP20x0), Intel x86, Pentium, Motorola PowerPC 750 и 74x0 (mpc7xx), Motorola PowerQUICC I (mpc8xx) и PowerQUICC II (mpc8260)

OSE

 

Windows, Solaris, Linux

PowerPC, ARM, MIPS, StrongARM, Intel IXP2400, TI OMAP ARM7/C55, PowerQUICC, XScale, M-Core, Coldfire, Infineon C16x, Xc16x, E-Gold, Tricore, NEC V850, Atmel AVR, Mitusbishi M16C, Intel 8051, DSPs (TI C5/C6, Starcore, Agere 16k, LSI Logic ZSP, TigerShark, ST Micro)

OS-9

 

Windows

Motorola 68K, ARM/StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 or Intel Pentium, Intel IXC1100 XScale

C EXECUTIVE

 

Windows, Solaris

x86, PowerPC, ARM, MIPS, 68K, i960,SH,TI

CMX-RTX

 

Windows

x86, PowerPC, ARM, MIPS, практически все 8-, 16-, 32-бит. процессоры

Inferno

 

Windows, Solaris, Linux

x86, PowerPC, ARM, MIPS, Sparc

INTEGRITY

POSIX 1003.1-2003

Windows, Solaris, Linux, HPUX

x86, PowerPC, ARM, MIPS, ColdFire, StrongARMXScale

INtime

 

Windows

x86

LynxOS

POSIX.1/.1b/.1c

Sun Solaris, SunOS, RS6000, LynxOS Native/Hosted

x86, 68k, PPC, microSPARC, microSPARC II, PA-RISC

Nucleus

 

Windows

x86, PowerPC, ARM, MIPS, Nios, Nios II, ColdFire, 68k, H8S, SH, DSP, OMAP, XScale, MCore

RTX

 

Windows

x86

CORTEX

 

Windows, Solaris, Linux

Hitach H8/300H, H8/S и SH-1/2/3, TI TMS320C3X, POSIX.4 ( SUN SPARC)

DeltaOS

 

Windows, Linux

x86, PowerPC, ARM, MIPS, Dragonball

Таблица 1. Характеристики ОСРВ

 

ОСРВ

Модель

Число уровн. приор.

Мах. число задач

Политики планирования

Состояния процесса/потока

Механизмы синхронизации/ взаимодействия

VxWorks

Задачи имеют 1 поток, все задачи выполняются в одном адресном пространстве без какой-либо защиты. Компонент VxVMI дает возможность каждой задаче выполняться в собственном. адресном пространстве

256

Ограничено размером доступной памяти

POSIX и Wind планирование, каждый вариант имеет Preemptive priority и Round-robin

9

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

QNX

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

64

4095 процессов, в каждом процессе до 32767 потоков

FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование

14

передача сообщений (очереди и почтовые. ящики), семафоры, мьютексы, флаги событий, сигналы POSIX

Windows CE

процессы/потоки, нити (fiber), неуправляемые ядром

256

32 процесса, число потоков внутри процесса ограничено доступной RAM

с приоритетами, циклическое между потоками на одном приоритетном уровне, если квант установлен в 0, поток выполняется до завершения

5: выполняется (running), приостановлен (suspended), спящий (sleeping), заблокирован (blocked), завершен (terminated)

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

pSOS

только потоки

256

Ограничено памятью

FIFO с приоритетами, циклическое

4: создан (created), готов (ready), выполняется (running), заблокирован (blocked)

семафоры, флаги событий, сигналы POSIX, очереди сообщений

ChorusOS

процессы/акторы/потоки

 

 

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

 

мьютексы, мьютексы реального времени, семафоры, флаги событий, LAP (Local Access Point), IPC (Inter-Process Communication) – сообщения, порты, группы портов, MIPC (почтовые. ящики), разделяемая память, очереди сообщений

OSE

 

32

 

FIFO с приоритетами

 

 

OS-9

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

65535

 

С приоритетами

 

 

C EXE-CUTIVE

 

32000

 

FIFO с приоритет., квантование времени

 

 

CMX-RTX

 

 

 

FIFO с приоритет., циклическое с приоритетами

 

 

INTEG-RITY

 

255

 

циклическое с приоритетами,ARINC 653

 

семафоры, мьютексы,

INtime

 

255

 

FIFO с приоритетами, циклическое с приоритетами

 

 

LynxOS

 

512

 

FIFO с приоритетами, циклическое с приоритетами, фиксированные приоритеты, квантование времени, динамические приоритеты

 

 

RTX

 

128

 

 

 

 

CORTEX

 

62

 

FIFO с приоритетами, циклическое с приоритетами, разделение времени, другие

 

мьютексы и условия, мониторы и условия, вычислительные семафоры, события

DeltaOS

 

256

 

 

 

 

Таблица 2. Характеристики многозадачной обработки

 

ОСРВ

Модель защиты

Поддержка MMU

Виртуаль-ная память

Подкачка

Вызов стр. по запросу

VxWorks

-без защиты
-защита виртуальной памяти (VxVMI)

не требуется, но поддерживается для VxVMI

да (для VxVMI)

нет

нет

QNX

защита виртуальной памяти

Да

да

да

нет

Windows CE

- защита виртуальной памяти
- без защиты

да или нет (зависит от конфигурации)

да

да, но можно запретить

да, но можно запретить

pSOS

- без защиты,
- защита кода, данных и пространства стека с помощью библиотечных функций (2 варианта –регионы и разделы)

не требуется

нет

нет

нет

ChorusOS

-без защиты,
-защищенная память,
-защита виртуальной памяти

да или нет (зависит от конфигурации)

да

да

да

OSE

 

Да

 

 

 

OS-9

 

Да

 

 

 

C EXEC-UTIVE

 

Нет

 

 

 

CMX-RTX

 

Да

 

 

 

INTEG-RITY

 

Да

 

 

 

INtime

 

Да

 

 

 

LynxOS

 

Да

 

 

 

RTX

 

Да

 

 

 

Таблица 3. Характеристики управления памятью

 

ОСРВ

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

Управление временем

 

Прерывания

Контекст

Стек

Взаимодействие прерываний с задачами

 

VxWorks

Вложенные, с приоритетами

Обработчики прерываний выполняются в отдельном контексте

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

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

Часы (clock), интервальный таймер

QNX

Вложенные, с приоритетами

Прерывание обрабатывается в контексте потока

Прерывание имеет свой собственный стек

Сигналы и импульсы

Часы (clock), интервальный таймер

Windows CE

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

ISR выполняется. в специальном контексте, при этом ISR использует виртуальные адреса, статическое. отображение. OEM. IST выступает как обычный поток приложения и имеет свой собственный контекст и приоритет.

IST выступает как обычный поток приложения и имеет свой собственный стек

Из ISR можно подать сигнал в IST только с помощью события. OEM может создать область разделяемой памяти с помощью статического отображения области памяти в адресное пространство ISR.

Часы (clock), интервальный таймер

pSOS

Вложенные, с приорите-тами

Прерывание выполняется в контексте потока

Стек ядра или стек прерывания в зависимости от целевой платформы

Через объекты взаимодействия и синхронизации

Часы (clock), интервальный таймер

ChorusOS

 

Обработчики прерываний выполняются в отдельном контексте

 

Флаги событий, MIPC

Универсальное интервальное время, виртуальный таймер, универсальное. время. часы истинного времени, сторожевой таймер, оценочный таймер

Таблица 4. Характеристики управления прерываниями, синхронизацией и временем различных ОСРВ

5 Операционные системы реального времени (список)

Свободные:

  1. ChibiOS/RT
  2. XOberon — ОСРВ для БПЛА, написана на Обероне SA
  3. RTLinux — ОС жёсткого РВ на основе Linux
  4. RTEMS — ОС с открытым исходным кодом, разработана DARPA МО США
  5. eCos
  6. Fiasco (клон L4)[12]
  7. OSA[13] — кооперативная многозадачная ОСРВ с открытым исходным кодом для микроконтроллеров PIC (Microchip) и AVR (Atmel)
  8. FreeRTOS
  9. KURT (KU Real Time Linux) — ОС мягкого РВ на основе Linux
  10. Phoenix-RTOS
  11. Nut/OS[14]
  12. Prex
  13. RTAI
  14.  scmRTOS — Single-Chip Microcontroller RTOS[15]
  15. SHaRK[16]
  16. Symbian OS
  17. TNKernel
  18. TRON Project
  19. Xenomai
  20. BeRTOS[17] — ОСРВ для встраиваемых систем с открытым исходным кодом, распространяется по лицензии GPL

Проприетарные:

  1. Automation Runtime — ОС жёсткого РВ для контроллеров B&R
  2. QNX — с открытым исходным кодом (начиная с версии QNX Neutrino 6.3.2)
  3. RTOS-32 — ОС с открытым исходным кодом
  4. Ardence RTX
  5. ChorusOS
  6. DNIX
  7. DMERT
  8. DSOS
  9. embOS (Segger)
  10. FlexOS
  11. HP-1000/RTE[18]
  12. INTEGRITY
  13. ITRON
  14. LynxOS
  15. MERT
  16. MicroC/OS-II
  17. MQX RTOS[19]
  18. Nucleus
  19. OS-9
  20. OSE
  21. OSEK/VDX
  22. OSEKtime
  23. PDOS
  24. Phar Lap ETS
  25. PikeOS
  26. Portos[20]
  27. pSOS
  28. REX
  29. RMX
  30. RSX-11 (её советский клон — ОСРВ СМ ЭВМ)
  31. RT-11
  32. RTOS-UH
  33. RTXC
  34. Salvo RTOS[21]
  35. SINTRAN III
  36. ThreadX
  37. VRTX
  38. VxWorks/Tornado
  39. Windows CE
  40. µnOS
  41. UNIX-RTR
  42. Virtuoso — ОСРВ для сигнальных процессоров DSP
  43. Багет — ОСРВ разработанная НИИСИ РАН по заказу МО РФ


 

А также другие работы, которые могут Вас заинтересовать

51699. День Збройних Сил України 38.5 KB
  Далі ми пропонуємо такі конкурси для хлопців: 1 конкурс Лівооооруч Хлопці мають вишикуватись у шеренгу. По команді ведучого вони мають різко рівнятися повертатися у той бік у який накаже ведучий. І тільки на РУЧ хлопці мають повертатися.
51700. Формування особистості в початкових класах 28.5 KB
  Особливу роль в цьому напрямку відіграє початкова школа. Початкова школа – це Школа радості школа добра родинного затишку милосердя постійного спілкування і співпраці родини вчителів і дітей спрямована на: розвиток природних здібностей; формування духовності; навчання добротворення і виховання почуттєвості через різні види діяльності.
51707. Типология уроков; особенности нетрадиционных уроков биологии, лабораторных и практических занятий 94 KB
  Нетрадиционные уроки биологии 1. В зависимости от решаемых дидактических задач и их количества различают специализированные и комбинированные уроки. Специализированные уроки. В нее входят: вводные уроки уроки изучения нового материала уроки повторения уроки проверки результатов обучения.