Паравиртуализация

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

В принципе, этот подход должен обеспечивать более высокую надежность, чем у отдельной операционной системы, поскольку при отказе виртуальной машины, содержащей один или несколько драйверов, эта виртуальная машина может быть перезапущена, а драйверы могут быть возвращены в исходное состояние. Здесь не предпринимаются попытки вернуть драйверы в состояние, предшествующее отказу, как это делается в Nooks. Измерения производительности показывают, что накладные расходы на использование паравиртуальных машин в такой манере составляют около 3-8%.

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

Пересказ Сергея Кузнецова статьи

Can We Make Operating Systems Reliable and Secure?

, , , Vrije Universiteit, Amsterdam.

Computer (IEEE Computer Society, V. 39, No 5, May 2006).

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

Кстати, именно эта статья вызвала новый виток дискуссии Эндрю Таненбаума с Линусом Торвальдсом (первый спор о микроядерном подходе возник еще в 1992 г.).

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

В современных операционных системах имеются две характеристики, делающие их ненадежными и небезопасными: они огромны и обладают очень плохой изоляцией сбоев. В ядре ОС Linux содержится более 2,5 миллионов строк кода, в ядре Windows XP - в два с лишним раза больше. В одном из исследований надежности программного обеспечения показано, что в программах имеется от шести до шестнадцати ошибок на 1000 строк исполняемого кода; в другом исследовании насчитывается от двух до 75 ошибок на 1000 строк исполняемого кода в зависимости от размера модуля.
При таких оценках ядро Linux содержит около 15000 ошибок, а Windows XP - больше 30000 ошибок. Еще хуже то, что около 70% кода операционных систем занимает код драйверов устройств, в которых ошибки встречаются в 3-7 раз чаще, чем в обычном коде. Понятно, что просто невозможно найти и исправить все ошибки; более того, при исправлении ошибок часто привносятся новые.

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

микроядро обрабатывает прерывания, обеспечивает

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

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



Поверх уровня драйверов устройств располагается уровень серверов. Файловый сервер является небольшой (4,500 строк исполняемого кода) программой, которая принимает запросы от пользовательских процессов по обработке Posix-совместимых вызовов, относящихся к файлам (read, write, lseek и stat) и выполняет их. На этом уровне находится и менеджер процессов, который поддерживает управление процессами и памятью и выполняет Posix-совместимые и другие системные вызовы, такие как fork, exec и brk. Несколько необычным является сервер реинкарнации, который является родительским процессом всех других серверов и всех драйверов. Если драйвер или сервер аварийно или по собственной инициативе завершается, либо не отвечает на периодические запросы отклика, то сервер реинкарнации принудительно завершает его, если это требуется, и перезапускает из копии на диске или в основной памяти.
В число других серверов входит сервер сети, поддерживающий весь стек TCP/IP; простой сервер имен, используемый всеми остальными серверами; и информационный сервер, способствующий отладке.

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

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

Надежность Minix 3 происходит из разных источников. Во-первых, размер кода, выполняемого в ядре, составляет около 4000 строк, и общее число ошибок - всего около 24. Небольшой размер ядра позволяет верифицировать его код вручную или на основе формальных методов. Особенности IPC позволяют избежать потребности управления буферами в ядре. Кроме того, для каждого процесса ограничены доступные примитивы IPC, включая адреса назначения и события, о которых происходит уведомление. Например, пользовательские процессы могут использовать только принцип рандеву и посылать сообщения только Posix-серверам. В дополнение к этому, все структуры ядра являются статическими.


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

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

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

В течение десятилетий мультисерверные архитектуры на основе микроядра критиковались за недостаточную эффективность. Однако различные проекты показали, что при модульной разработке можно достичь приемлемой производительности. Несмотря на то, что система Minix 3 не оптимизировалась для достижения высокой производительности, она работает достаточно быстро. Вынос с ядра драйверов привел к снижению производительности на 10%, и система собирается, включая ядро, общие драйверы и все серверы (112 компиляций и 11 редактирований связей) менее чем за 6 секунд на процессоре Athlon с 2,2 Ггц. Тот факт, что мультисерверная архитектура смогла обеспечить высоконадежную Unix-подобную среду за счет небольшого снижения производительности, показывает практичность этого подхода.Minix 3 для Pentium свободно распространяется под лицензией Беркли на сайте www.minix3.org.

Проект Nooks

К счастью, ситуация не является безнадежной. Исследователи прилагают усилия к созданию более надежных операционных систем. Авторы статьи рассматривают четыре подхода, используемые исследователями для придания будущим операционным системам более высокого уровня надежности и безопасности. Наиболее консервативным является подход проекта Nooks, направленного на повышение надежности существующих операционных систем (таких как Windows и Linux). В Nooks поддерживается монолитная структура ядра, но ядро защищается от содержащих ошибки драйверов устройств путем обертывания каждого драйвера уровнем защитного программного обеспечения. Оболочка драйвера тщательно отслеживает все взаимодействия между драйвером и ядром. Целями проекта Nooks являются защита ядра от сбоев драйверов, автоматическое восстановление после отказа драйвера и достижение всего этого путем небольших изменений в существующих драйверах и ядре. Первая реализация была выполнена для Linux, но идеи применимы и к другим унаследованным операционным системам.

Хотя эксперименты показали, что Nooks может перехватить 99% фатальных ошибок драйверов и 55% их прочих ошибок, система не является совершенной. Например, в драйверах могут выполняться привилегированные команды, которым в них выполняться не полагается; в них может производиться запись в неверные порты; в них могут возникать бесконечные циклы. Кроме того, группе Nooks пришлось вручную написать большое число оболочек драйверов, и в них самих могут содержаться ошибки. Наконец, не предотвращается полностью возможность доступа по записи ко всей памяти. Тем не менее, этот проект является потенциально полезным шагом к повышению надежности унаследованных операционных систем.

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

Проект Singularity

Наиболее радикальный подход предложен в Microsoft Research. По существу, этот подход отвергает понятие операционной системы как единой программы, выполняемой в режиме ядра, плюс некоторый набор пользовательских процессов, выполняемых в режиме пользователя, и заменяет его системой, написанной на новом типизированном языке, в котором отсутствуют проблемы с указателями и пр., свойственные C и C++. Подобно двум предыдущим, этот подход существует десятилетия. Он использовался в компьютере Burroughs B5000. Тогда единственным доступным языком был Algol, и защита поддерживалась не устройством управления памятью, а за счет невозможности генерации "опасного" кода компилятором языка Algol.

Система, называемая Singularity (http://research.microsoft.com/os/singularity), пишется почти целиком на новом типизированном языке Sing#. Этот язык основан на C#, но дополнен примитивами передачи сообщений, семантика которых определяется формальными, письменными контрактами. Поскольку безопасность языка строго ограничивает поведение системы и процессов, все процессы выполняются в едином виртуальном адресном пространстве. Эта схема ведет как к безопасности (поскольку компилятор не позволяет процессу обращаться к данным любого другого процесса), так и к эффективности (поскольку устраняется потребность в обращениях к ядру и переключениях контекста).

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

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

Хотя большая часть микроядра написана на Sing#, небольшая часть написана на C#, C++ и языке ассемблера, и этой части приходится доверять, поскольку верифицировать ее невозможно. Доверенный код включает уровень абстракции аппаратуры и сборщик мусора. Уровень абстракции аппаратуры скрывает от системы низкоуровневые детали аппаратуры, такие как порты ввода-вывода, пути запроса прерываний, каналы прямого доступа к памяти и таймеры. Остальной части операционной системы предоставляется машинно-независимая абстракция.

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

В Singularity поддерживается совместно используемая процессами "куча" объектов, но в каждый момент времени каждый объект из кучи принадлежит только одному процессу. Однако владение объектом может быть передано другому процессу через канал. Например, когда драйвер диска считывает блок, он помещает этот блок в кучу. Потом система передает дескриптор (handle) этого блока процессу, запросившему данные, поддерживая принцип единственного владельца, но позволяя передавать данные без копирования.



Для всех служб в Singularity поддерживается единое иерархическое пространство имен. Сервер корневого имени управляет верхней частью дерева, но к его узлам могут монтироваться другие серверы имен. В частности, файловая система, которая является всего лишь процессом, монтируется к узлу /fs, так что /fs/users/linda/foo может быть именем пользовательского файла. Файлы реализуются в виде B-деревьев, ключами которых являются номера блоков. При обработке системных вызовов файловая система требует от дискового драйвера поместить в кучу нужные блоки. Затем владение блоком передается по цепочке пользовательскому процессу.

Для каждого компонента системы имеются метаданные, описывающие его зависимости, экспортирование, ресурсы и поведение. Эти метаданные используются для верификации. Образ системы состоит из микроядра, драйверов и приложений, требуемых для выполнения системы, и их метаданных. Внешние верификаторы могут выполнить многочисленные проверки образа до запуска системы; в частности, таким образом можно убедиться в том, что драйверы не конфликтуют по ресурсам. Верификация состоит из трех шагов. Сначала компилятор контролирует типы, владение объектами, протоколы каналов и т.д. Затем компилятор генерирует внутреннее представление на языке MSIL (Microsoft Intermediate Language), переносимый байт-код, который может проверяться верификатором. Наконец, представление системы на MSIL компилируется в командный код x86 компилятором постобработки, который может вставлять в код проверки времени выполнения. Такая избыточная верификация служит для отлавливания ошибок в самих верификаторах.

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

Eclipse - пришелец из открытых систем

Известно несколько попыток создать "открытую" среду разработки. Это вполне естественно, если сложить три составляющие: разработчики нуждаются в консистентной, универсальной и настраиваемой среде разработки; никто не хочет платить лицензионные отчисления владельцам "фирменных" технологий; наконец, крупные корпорации, понимая важность создания инфраструктуры вокруг своих конечных продуктов, осуществляют щедрый contribution в мировое сообщество разработчиков.

Одним из самых перспективных кандидатов среди "контрибьюшинов" в сфере разработки ПО был и остается Eclipse - IDE-среда разработки, созданная на базе оболочки Websphere Studio Workbench компании IBM. Eclipse написан на Java - таким образом, проблема переносимости и универсальности этой среды решена изначально. Модульная архитектура Eclipse позволяет разработчикам и потребителям этой технологии свободно модифицировать, встраивать и добавлять возможности без перекомпиляции всего кода, адаптируя возможности Eclipse под свои нужды.

Exit (0);

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

Истинное микроядро

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

Сообщения передаются через "шину сообщений", по которой проходят все сигналы по подключению и отключению программных компонент "на лету". Следствие из общей шины сообщений - это экстраполяция локального IPC на процессорные кластеры. Если одно ваше приложение вызывает другое через системный вызов (а иных возможностей фактически и нет), то IPC прозрачно транслируется на другой процессор - и в результате приложения общаются тоже прозрачно. Применение кластерного механизма - доступ к ресурсам другого процессора, такого как файловые системы, устройства или сетевые подключения, без включения сетевых протоколов (кроме встроенного в ядро протокола Qnet). На основе такого доступа можно строить экстремально "тонкие" клиенты, все ресурсы получающие по сети. Протокол Qnet будет осуществлять маршрутизацию и баланс сетевого трафика - прозрачно для приложений. Сам Qnet работает практически через любую среду, например Ethernet или Internet (конечно, такой IPC будет крайне зависимым от среды).

Помимо процессорных кластеров, QNX поддерживает также и SMP для отдельных потоков - естественно, что приложение должно быть спроектировано для многопоточной среды, чтобы получить выгоду от работы на нескольких процессорах. Использование SMP можно комбинировать с Qnet для построения кластеров как одно-, так и много- процессорных систем - перекомпиляции приложений не потребуется.

История

QNX - компания легендарная и во многом загадочная, как, впрочем, и сама система. Загадочная, потому что продукция этой компании, операционная система QNX, использовалась и используется в самых критических и стратегических областях, таких как аэрокосмическая промышленность, энергетика, в том числе и ядерная, а также (насколько об этом можно судить) в военных разработках. Легендарной же QNX можно назвать хотя бы по той простой причине, что в течение двадцати лет у этой системы реального времени нет и никогда не было сколько-нибудь значительного конкурента. Все эти встроенные Linux и DOS, не говоря о Windows, даже и не приближались к лидеру в плане надежности кода и устойчивости интерфейсов.

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

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

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

Кросс-разработка? Un Momentics

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

Основные особенности Momentics, унаследованные от Eclipse, это возможность подключать модули для различных целевых процессоров (x86, MIPS, PowerPC, ARM, StrongARM, XScale, SH-4), различных языков программирования (C, C++, Embedded C++, Java) и различных платформ разработчика (Windows, Solaris или в собственном режиме под QNX Neutrino). Помимо прочего, Momentics располагает согласованным под всеми платформами интерфейсом, построенным по принципу "передачи токена внимания" (то есть нужные инструменты и окна всплывают по мере необходимости).

Хотя набор возможностей Momentics может показаться аскетическим, по мере работы вы обнаружите, что под простым интерфейсом скрыто гораздо больше, чем кажется на первый взгляд. В частности, реализованы QNX-специфические Wizards, сквозной поиск теста в проекте (типа Find in Files), управление проектами и ставший в открытых системах стандартом де-факто механизм групповой разработки и контроля версий CVS.

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

Особое отличие среды Momentics (как, впрочем, и Eclipse или Sun ONE Studio) - это немодальная отладка. То есть вы можете выполнять один или несколько фрагментов кода, причем они могут выполняться на разных "целевых" платформах и быть написанными на разных языках. Дополнительные опции - подключение к уже запущенному процессу и анализ дампа "свалившегося" процесса.
Естественно, поддерживаются все типы отладки: точки останова, пошаговое прохождение, просмотр стека и переменных.

Визуальные возможности - такие как список "ToDo", формируемый на основе возникших ошибок компиляции, подсказки при наведении курсора на переменные, сохранение рабочей области и прочие "радости разработчика" - будут хорошо знакомы вам по другим известным IDE. Кроме того, в наличии все средства редактора: раскраска, автоотступы, отображение структуры проекта (файлов, классов, модулей), автодополнение ввода и т.д.

Помимо основных средств кроссплатформенной компиляции, Momentics снабжен несколькими инструментами, специфичных для отладки встроенных систем. Уникальный инструмент - сборщик загрузочных образов, собирающий все необходимые библиотеки и файлы вашего проекта для записи на загрузочный CD или для прожигания на ROM-диск. При этом отслеживаются зависимости библиотек: все нужные библиотеки будут включены, все ненужные функции из них будут удалены - это особенно важно, если объем памяти целевой платформы ограничен.

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

Подальше от спутников, поближе к "чайникам"

Перечисленные выше возможности QNX - это, так сказать, "родные" и изначально критичные для системы характеристики. Но, вместе с тем, разработчикам было не чуждо стремление приблизить систему к разработчику приложений, сделать среду QNX популярной и коммерчески состоятельной на новых рынках бытовой техники.

Для этого был создан несколько аскетический, но вполне приятный и самодостаточный интерфейс пользователя - Photon MicroGUI. Он предоставляет все основные примитивы графической оконной системы: окна, кнопки, меню и так далее. Позднее появление этой оболочки сыграло положительную роль - в нее изначально были заложены современные идеи, так сказать "символы" XXI века: полная поддержка Unicode, "плугабельно-скинабельный" интерфейс (то есть как внешний вид, так и функциональность штатно могут быть изменены во время работы), встроенный интерфейс с Java (Java получает отдельные окна в качестве своего viewpoint).

QNX и базы данных

Одним из самых критических приложений для разработчика является система управления базами данных, RDBS. Поэтому нелишним будет знать, что QNX изначально поддерживает RDBMS Empress (производимую одноименной компанией - Empress Software). Эта RDBMS изначально создавалась для QNX - и, следовательно, была оптимизирована для встроенных приложений и ограниченных ресурсов. Тем не менее, система поддерживает методы доступа SQL, ODBC и JBDC и обладает всеми признаками "взрослых" СУБД.

Узнать больше о продуктах Empress и получить их тестовые версии можно на .

document.write('');

This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009

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

Мы предлагаем: «Гермес».

QNX и Virtual PC

Как-то в статье о VMWare (К+П, № 3/2003) я допустил ошибку - сказал, что QNX работает в этой среде, за что получил замечание от внимательного читателя. Совершенно верно: QNX не работает под VMWare, он работает под Virtual PC - имейте это в виду, если это для вас важно.

Внимание! Хотя QNX способна работать на самых непритязательных "камнях", под VPC она почему-то очень любит "поедать" такты вашего процессора. VPC по определению не может получить больше 50% среднестатистической мощности в фоновом режиме - но в режиме переднего плана, даже без фокуса ввода, претендует на все 100%. Так что, запуская QNX под Virtual PC, не стоит уводить VPC в фон и параллельно играть в игры, воспроизводить MP3, смотреть кинофильмы или запускать архиватор - в противном случае вы рискуете повесить "вычислители" в QNX, в частности менеджер пакетов, интенсивно использующий ресурсы процессора для разархивации.

Долгие годы QNX была системой

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

Официально QNX называется RTOS, Run Time Operating System. В основе QNX, как и раньше, лежит компактное и стабильное настоящее микроядро. Поскольку система рассчитана на 100-процентно бесперебойную работу, то архитектура ядра и окружения предполагает динамическую конфигурацию - установка и удаление драйверов, сетевых протоколов, файловых систем, оконных интерфейсов и т. п происходит в режиме "hot plug", без прекращения работы. Все перечисленные компоненты работают в отдельных адресных пространствах, без типичных для других систем "оптимизаций" по заносу подключаемых компонент в монолитное или составное ядро. Как следствие - QNX умеет восстанавливать себя практически после любого программного сбоя, любой компонент может быть "признан недействительным" и повторно запущен. Существуют точки восстановления, "неразрушающей перезагрузки", после которой система блокирует участки кода, которые вызвали сбой (исключение), и продолжает работу без потери состояния, очистки памяти и инициализации процессора.

QNX в России

Если вы думаете, что все описанное - далеко и недоступно, вы ошибаетесь. Система QNX активно продвигается на просторах СНГ и, в частности, в России. Интересы QNX на всем постсоветском пространстве с 1996-го года представляет компания SWD Software Ltd. Эта же компания проводит ежегодную конференцию "QNX-Россия".

Совместимость? Без проблем

Первоначально QNX 6 задумывалась как POSIX-совместимая система - POSIX API был реализован на самом раннем этапе, так что нет никакой "библиотеки POSIX-совместимости" или чего-то подобного. Если вы привыкли к программированию в Unix или Linux, можете продолжать в том же духе и под QNX, проблем не возникнет. Помимо прочего, "родной" POSIX занимает меньше места в памяти и быстрее работает.

Среда разработки - плацдарм атаки на TTM

Что сегодня особенно важно на рынке ПО - это сокращение времени выхода на рынок (TTM, Time To Market). Для быстрого создания новых приложений необходима "дружественная" среда разработки приложений. Пренебрежение этим фактом делает продвижение среды или технологии весьма проблематичным. Например, отсутствие (или недостаток) комфортабельных условий для разработки сдерживает разработку под Plan9 - хотя с технической стороны эта система дает фору многим другим "исторически сложившимся" системам.

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

Инсталляция

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

Вся установка проходит в текстовом режиме. Начинается она с предложения создать дисковые разделы, с чем можно согласиться, нажав Enter, или поспорить, нажав Esc, после чего следует перезагрузка. Можно также нажать клавишу v

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

Далее (правда, после принудительного знакомства с текстом лицензионного соглашения) идет выбор физических дисков для инсталляции (если их в системе более одного, разумеется). Диски маркированы достаточно понятно - /dev/hd0, dev/hd1 и т.д.

По выборе диска скорее всего появится сообщение о том, что таковой имеет объем более 8,4 Гбайт (а где вы нынче меньше-то найдете) и потому со старыми BIOS могут возникнуть проблемы при загрузке. Для устранения которых предлагаются следующие опции:

установка QNX в пределах первых 8,4 Гбайт;

установка стартовой части QNX в том же диапазоне;

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

Поскольку ни на одной современной "маме" проблем с загрузкой возникнуть не должно, скорее всего, можно выбрать последний вариант. Я, правда, остановился на первом, так как заранее разбил (средствами Linux) свой второй физический диск (8-гигабайтник Fujitsu) на три раздела - два по 3 Гбайт и последний - все, что осталось. И предполагал временно поселить QNX на первый из них.

Далее предлагается указать источник инсталляции (задумчиво именуемый filesystem), в качестве какового предлагался CD ROM, обозначенный как dev/cd0. Вслед за чем система радостно сообщила мне, что помещения (именно так, room) для QNX у меня нет. Что не удивительно - все три раздела получили по умолчанию файловую систему ext2fs.

Однако тут же был предложен и выход из положения. Либо:

указать раздел для удаления;

переразбить разделы, для чего настоятельно советуется Partition Magic; если с этим согласиться, следует немедленная перезагрузка;

установить QNX внутрь одного из существующих чуждых разделов, в качестве которых допускались разделы Windows и Linux.

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

Partition Type OS Size 1 131 Linux 2963M 2 131 Linux 2963M 3 131 Linux 2329M 4 0 Unused 0M

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

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

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

А во-вторых, заботливо сообщалось, что винт мой работает в режиме DMA. И если перезагрузка не пройдет, режим этот следует отключить. Принял к сведению и нажал, как предлагалось, Enter для перезагрузки.Каковая и не замедлила воспоследовать...

Первый запуск

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

По умолчанию swap-файл предлагался в 256 Мбайт (что было равно объему оперативной памяти). Пока я размышлял на тему - а оно мне нужно, - система приняла мое молчание за согласие и, сказав, что swap-файл благополучно создан, продолжила загрузку.

А именно - спустя пару секунд появилось сообщение о новой видеокарте и псевдографическая заставка на предмет определения ее параметров. В качестве карты была автоматически предложена TNT (что недалеко от истины - у меня была Riva TNT2 M64) с вариантами для выбора - VGA и VESA. Разрешение предлагалось установить 1024*768, глубину цвета - 16 бит, частоту обновления - 60 Hz. Для первого параметра возможны варианты - от 640*480 до 1600*1200, для второго - от 8 до 32 бит, для третьего - 70, 75 и 80 Hz.

По завершении установок их следовало протестировать. Что я и проделал при обоих приемлемых для меня разрешениях - 1024*768 и 1152*864. Результаты чего меня отнюдь не вдохновили: какие бы частотные характеристики я не устанавливал, система автоматически сваливалась на те же 60 Hz, что были отмечены по умолчанию. А при большем из разрешений, кроме того, выше 8-битного цвета получить не удавалось.

Так что я с легкой душой снял отметку с опции загрузки системы Photon при входе в систему и двинулся дальше. После чего было предложено авторизоваться - тем не менее, в графическом режиме. Следуя рекомендации из предыдущего раздела, я авторизовался как root - и через считанные мгновения (не большие, чем загрузка Windows 3.1 на Pentium-II) оказался в том самом Photon'е - оригинальной графической среде, специально разработанной для QNX.

Система Photon сама по себе весьма интересна, и я рассчитывал уделить толику времени ее изучению. И даже успел кое-что в этом направлении предпринять. Однако в дальнейшем жизненные обстоятельства мои изменились, и QNX пришлось пожертвовать. И более - увы - руки до нее не доходили. Хотя воспоминания сохранились самые приятные...

QNX: очень краткие заметки

Вступление. Эта заметка была написана очень давно - весной 2001 года. Где она была размещена - хоть убейте, не помню. Тем не менее, в связи с недавними событиями - частичным открытием исходников QNX, - она снова приобрела некоторую актуальность: с внешней стороны эта ОС изменилась очень мало. В связи с чем заметка и переразмещается на этих страницах.

операционная система реального времени, предназначенная

Все знают, что QNX - Unix-подобная (или, точнее, более-менее POSIX-совместимая) операционная система реального времени, предназначенная для промышленного использования и встроенных систем, основанная на микроядре. Если кто не знает - об этом есть что почитать. Как ни странно, русскоязычных материалов (и весьма информативных) на эту тему в Сети немало.
Что заставило меня обратиться к этой теме? Ведь QNX - отнюдь не свободная, вовсе не открытая (до недавнего времени - А.Ф.) и даже не бесплатная ОС. Более того, система эта при официальном ее приобретении для коммерческого использования очень даже дорогая.
Однако для некоммерческого применения - она бесплатна. То есть download-версию ее можно спокойно (и легально) использовать на своей домашней машине. А ведь это именно тот аспект применения, который более всего интересует меня в любой ОС. При том, что национальная постсоветская тяга к халяве у меня ослаблена: если из использования системы извлекается прибыль - не грех и заплатить. Тем более, что Господь велел делиться, как говорят в определенных кругах...
И конечно, мной двигало самое обычное любопытство: интересно было посмотреть на систему, в существенно отличную архитектурно от всего, что я видел до сих пор. Тем более, что удовлетворить ее было довольно просто: на сайте фирмы QSSL () для свободного скачивания имеется не только сама система (текущая ее версия именуется QNX/Neitrino, или QNX6), но и подборка прикладного софта для нее. Все это - оформлено в виде iso-имиджа CD ROM, общим объемом тогда более 200 Мбайт (нынче, говорят, под 600). Поскольку сама система, как известно, занимает считанные дискеты, такой объем внушал надежду, что софта этого - много (полный дистрибутив OpenBSD, например, лишь немногим больше, а в нем есть почти все, нужное "на десктопе".
Так что, выбрав толику времени, я скачал образ, записал с него диск и взялся устанавливать QNX. В результате чего и начат настоящий цикл заметок. Никаких подробностей и никакой глубины проникновения в суть вещей не обещаю. Все пишется исключительно на предмет расширения кругозора. Но мне показалось интересным.

Аннотация.

В статье рассматривается задача построения операционной системы реального времени (ОСРВ) для цифрового сигнального процессора. Описывается конкретная реализация ОСРВ MicroDSP-RTOS, разработанная в ИСП РАН. Рассматривается архитектура ОС и предоставляемые функции. Кроме того, описываются доработки в инструментарии кросс-разработки MetaDSP для обеспечения эффективной разработки и отладки многозадачных приложений под платформу MicroDSP-RTOS.

Использование процедур обработки прерываний

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

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

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

Литература

1.	С. Сорокин. Как много ОС РВ хороших… Современные технологии автоматизации, 2/1997, стр. 7-11
2.	С. Сорокин. Windows. Современные технологии автоматизации, 2/1997, стр. 18-20
3.	С. Сорокин. Системы реального времени. Современные технологии автоматизации, 2/1997, стр. 22-29
4.	Comparison between QNX RTOS V6.1, VxWorks AE 1.1 and Windows CE .NET. Dedicated Systems Experts
5.	А. Жданов. Операционные системы реального времени. PCWeek, 8/1999.
6.	А. Жданов, А. Латыев. Замечания о выборе операционных систем при построении систем реального времени. PCWeek, 1/2001
7.	А. А. Жданов. Что день грядущий нам готовит? (В связи с появлением Windows NT на рынке ОСРВ).
8.	А. А. Жданов. Современный взгляд на ОС реального времени.
9.	В. Семенюк. Системы реального времени.
10.	T. Samuelsson, M. Åkerholm, Department of Computer Science and Engineering; P. Nygren, J. Stärner, L. Lindh. A Comparison of Multiprocessor RTOS Implemented in Hardware and Software. Computer Architecture Laboratory, Mälardalen University, Västerås, Sweden.

Общая функциональность

Всего в системе может присутствовать максимум 63 пользовательских задачи. Сами задачи являются обычными функциями без параметров, чаще всего представляющими собой бесконечный цикл. Каждой задаче соответствует приоритет от 0 до 62, задаваемый при подключении, причём не может существовать двух задач с одинаковыми приоритетами. Системное время квантуется, и в каждый квант времени выполняется задача, имеющая наивысший приоритет (самый высокий приоритет соответствует значению 0) среди тех, которые не находятся в состоянии ожидания. На приведённой ниже схеме (Рис. 1) можно видеть основные состояния, в которых может находиться задача, и возможные переходы между состояниями.

Рис.1.Схема переключения состояний задач

После истечения каждого кванта времени (system tick) вызывается функция обработки прерывания таймера. Эта функция выполняет следующие действия:

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

В системе всегда присутствует одна внутренняя задача, называющаяся background и имеющая самый низкий возможный приоритет - 63. Это значение ниже приоритета любой из пользовательских задач, и поэтому эта задача выполняется только тогда, когда все пользовательские задачи находятся в состоянии ожидания; таким образом, задача background является индикатором простоя системы. В начальной реализации эта задача представляла собой цикл, состоящий из нескольких инструкций NOP. В дальнейшем туда была добавлена инструкция IDLE, которая останавливает процессор до тех пор, пока не появится запрос на прерывание. Тем самым было снижено энергопотребление процессора на время простоя.

Очереди сообщений.

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

ОСРВ MicroDSP-RTOS

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

Поддержка MicroDSP-RTOS в MetaDSP

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

Работа с динамической памятью

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

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

Разработка ОС реального времени для цифрового сигнального процессора

В. В. Рубанов, К. А. Власов,
Труды Института системного программирования РАН

RTOS Illuminator

Этот инструмент представляет собой встроенную утилиту для наблюдения за состоянием процессов и управления ими извне. Визуально RTOS Illuminator является присоединяемым окном в среде MetaDSP, в котором на нескольких вкладках отображено состояние подключённых на данный момент задач.

На Рис. 2 показана вкладка Tasks.

Увеличить

Рис. 2.Вид окна RTOS Illuminator, управление задачами

Она позволяет просматривать текущее состояние процессов: имя процесса (имя подключаемой функции, поле Name), приоритет (поле Priority), текущий статус процесса (Status). Если задача приостановлена или находится в состоянии ожидания, для неё отображается значение таймаута (Delay), а для задач, ожидающих наступления некоторого события, дополнительно указывается, какое именно это событие (Event). Для выполняемой в данный момент задачи также указываются количество тактов, прошедшее с момента последнего переключения на эту задачу (Resumed Cycles), и текущий адрес выполнения (Run Address). Для неактивных задач в поле Run Address выводится адрес программной памяти, с которого будет продолжено выполнение задачи. Двойным щелчком мыши по этому полю можно перейти к тому месту исходного кода, которое соответствует указанному адресу, т. е. по сути, к той точке выполнения, в которой задача была прервана.

Помимо этого в этой вкладке можно изменять состояние задач, а именно:

отключить задачу (команда Disconnect Task в системном меню); перевести задачу из режима ожидания, блокировки или приостановленного состояния в режим готовности (команда Make Task Ready); изменить приоритет задачи (редактированием значения в поле Priority); изменить значение таймаута (при выставлении таймаута в 0 задача, находящаяся в приостановленном состоянии будет переведена в режим готовности, а для задач, ожидающих наступления какого-либо события значение 0 будет означать бесконечное время ожидания);

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

На Рис. 3 показана вкладка Events.

Увеличить

Рис. 3. Вид окна RTOS Illuminator, управление объектами синхронизации

На этой вкладке отображаются все объекты межзадачного взаимодействия и синхронизации, созданные программой. Для каждого объекта выводятся его адрес (в поле Name), тип объекта (сигнал, семафор, почтовый ящик и т. п., поле Type) и список задач, ожидающих данный объект синхронизации (поле Waiting Tasks). Для сигналов и семафоров дополнительно выводится счётчик, представляющий собой текущее состояние объекта (Counter), а для почтовых ящиков и очередей сообщений - указатель на сообщение, если оно присутствует (Message).

Так же, как и во вкладке Tasks, слева от каждого объекта присутствует флажок, который включает/отключает точку останова, выполняющуюся при наступлении отмеченного события.

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

Вкладка RTOS Info отображает сведения о системе RTOS в целом: количество тактов, прошедшее с момента последнего срабатывания таймера, длительность кванта времени, общее число квантов времени, прошедшее с момента старта системы, и версию RTOS.

RTOS Profiler

Рис. 4. Вид окна RTOS Profiler, последовательность задач

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

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

Рис. 5. Вид окна RTOS Profiler, распределение времени по задачам

В этой вкладке окна профилировщика отображается, какую часть процессорного времени занимала каждая задача. Опционально можно также отобразить суммарное время выполнения для системной фоновой задачи (background), для процедуры обработки таймерного прерывания (RTOS ISR - Interrupt Service Routine), по которому RTOS выполняет переключение задач, и процедуры начальной инициализации (Bootstrap).

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

Семафоры.

В MiscoDSP-RTOS реализованы двоичные семафоры и семафоры со счётчиком. Как те, так и другие обычно используются для обеспечения контроля работы с общими ресурсами.

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

Отличие семафоров со счётчиком от нескольких двоичных семафоров состоит только в том, что ресурсы могут использоваться несколькими задачами одновременно. Например, если есть канал передачи данных, состоящий из четырёх параллельных линий, работающих независимо, то для работы с ним может использоваться семафор со счётчиком, изначально равным 4. Когда задаче требуется линия передачи данных, она делает системный запрос. В результате, если количество доступных линий больше нуля, оно уменьшается на 1; в противном случае задача переводится в режим ожидания до тех пор, пока одна из задач, блокирующих ресурсы, не освободит используемую линию. Стоит отметить, что данный подход существенно отличается от использования нескольких двоичных семафоров. Семафор со счётчиком не делает различия между контролируемыми им ресурсами. В вышеприведённом примере задача, ожидающая ресурс, переводится в состояние готовности при освобождении любой из четырёх линий. При использовании же четырёх двоичных семафоров пришлось бы ждать освобождения какой-то одной конкретной линии, даже если все остальные уже свободны.

Сигналы.

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

Синхронизация и взаимодействие задач

Для синхронизации задач и взаимодействия их друг с другом предусмотрены следующие механизмы:

сигналы; семафоры; сообщения; очереди сообщений.

Сообщения.

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

Управление задачами

Подключение задачи.
Задачи подключаются динамически, поэтому в начале нужно явно вызвать функцию подключения для каждой задачи, которая будет выполняться. При подключении задача добавляется во внутренние структуры данных системы, стек инициализируется стартовым контекстом, который будет восстановлен при первом переключении на эту задачу. Отключение задачи.
Эта функция полностью удаляет задачу из всех внутренних структур данных операционной системы, и дальнейшая работа с этой задачей становится невозможной. Для повторного использования задачи её требуется снова подключить, после чего выполнение задачи пойдёт с самого начала. Приостановка выполнения задачи.
Выполнение задачи может быть на время приостановлено. Это может потребоваться, например, чтобы запустить выполнение менее приоритетной задачи, имея более приоритетную активную задачу. При вызове функции указывается длительность задержки в квантах времени. По истечении этого времени задача переводится в состояние готовности и, если она является наиболее приоритетной, получает управление. Восстановление из приостановленного состояния.
Эта функция позволяет при необходимости досрочно поставить приостановленную задачу в очередь на выполнение, переведя её в состояние готовности. Блокировка задачи.
Блокировка задачи очень похожа на отключение. Единственное отличие состоит в том, что при блокировке состояние задачи полностью запоминается и может быть восстановлено путем вызова соответствующей функции, после чего задача продолжит выполнение с того же места, где была остановлена. В случае же отключения продолжить выполнение задачи нельзя, её можно только подключить заново, и она начнёт выполняться с самого начала. Вывод из режима блокировки.
Эта функция выполняет действие, обратное блокированию. Состояние задачи восстанавливается в то, которое было до блокировки, за одним только исключением: если задача выполнялась, она переводится в состояние готовности, а не выполнения. Таймаут (для состояний приостановки и ожидания) начинает уменьшаться с каждым квантом времени; задача может получать сигналы и сообщения и так далее. Получение данных, переданных задаче.
При подключении задачи ей можно передать какие-либо данные (один из параметров функции подключения - адрес произвольной структуры данных). Данная функция позволяет получить этот адрес, чтобы иметь возможность обратиться к переданным данным. Изменение приоритета задачи.
Данная функция позволяет изменить приоритет любой задачи (при этом новый приоритет не должен быть занят). Для удобства работы, чтобы не нужно было запоминать и определять, каким приоритетом обладает каждая задача в каждый момент времени, обращение к задачам производится через уникальные идентификаторы. По сути, эти идентификаторы являются переменными, содержащими реальные значения приоритетов задач. В результате к задаче, скажем, номер 3 всегда можно обращаться через переменную TASK3, не задумываясь о том, менялся ли у неё приоритет, и если менялся, то какой он сейчас, поскольку эта переменная всегда будет содержать корректное текущее значение приоритета.

В настоящее время всё большую

В настоящее время всё большую роль начинают играть встраиваемые системы на основе цифровых процессоров обработки сигналов (ЦПОС). ЦПОС используются практически во всех областях деятельности человека - в быту, науке, медицине. Важнейшим программным компонентом, лежащим в основе функционирования таких систем, является операционная система, которая позволяет запускать одновременно несколько разных программ и организовывать взаимодействие между ними для решения одной общей задачи. Для встраиваемых систем обработки сигналов характерны операционные системы реального времени (ОСРВ). Эти системы применяются в тех случаях, когда главная задача - успеть среагировать на событие в рамках строго определенного максимального времени реакции. Например, это может быть сигнал на датчике, отображающем текущее состояние какого-то объекта в реальном времени. Возможна ситуация, когда состояние объекта на короткое время меняется, а потом возвращается обратно, и если это изменение останется незамеченным и необработанным системой, последствия могут быть самыми разными - от совершенно безобидных до катастрофических.
Важно также отметить, что возможность «успеть среагировать на событие» вовсе не означает высокую скорость работы. Система может работать относительно медленно, и всё же являться системой реального времени. Главное отличие ОСРВ от ОС общего назначения - это некий фиксированный промежуток времени, в течение которого система гарантированно среагирует на событие и выполнит его обработку. Величина этого промежутка времени определяется решаемой задачей и является одним из требований к разрабатываемой системе. Он может быть очень коротким, но может быть и длинным, важно лишь то, что он фиксирован и известен заранее.
Применение систем реального времени может быть самым разнообразным. Рассмотрим, например, работу сотового телефона. Его процессор должен выполнять одновременно довольно много задач: приём и кодирование речи при разговоре, отправку закодированного звука на ретрансляционную станцию, приём входящего закодированного звукового потока, раскодирование и воспроизведение его; плюс к этому необходимо обмениваться со станцией всякого рода служебной информацией - такой как переход из зоны в зону и переключение на другую станцию, отслеживание уровня сигнала, при необходимости - усиление его и так далее.
Причём многие из этих задач должны выполняться в реальном времени, без задержек. Например, задержка в обработке сигнала с микрофона приведёт к тому, что часть фразы будет утеряна; запаздывание с переключением на другую ретрансляционную станцию может привести к потере связи и разрыву соединения. Таким образом, применение операционной системы реального времени в данной ситуации не только оправдано, но и необходимо.
В данной статье мы рассмотрим операционную систему реального времени, разработанную в ИСП РАН для частной «системы на чипе» (System-On-Chip) на базе цифрового сигнального процессора MicroDSP 1.1, когда на одном общем кристалле размещаются сам процессор, модули расширения, программная память и два банка памяти данных. Размещение их на одном кристалле позволяет обеспечить очень быстрый доступ к ячейкам памяти (обращение к памяти занимает один такт). Размер банков памяти данных может меняться от 0 до 65536 16-битных слов; они независимы, и к ним можно обращаться одновременно. Программная память может составлять до 256К слов (4 страницы по 64К слова), размер слова составляет 24 бита (длина инструкций процессора). Стек организуется программно, при помощи трёх специальных регистров, содержащих границы стека и текущее положение указателя стека. Процессор поддерживает до 15 программируемых прерываний с индивидуальной настройкой приоритетов и маскированием, а также доступны три таймера.
Предполагалось, что система будет работать одновременно не более, чем с 64 задачами. Каждая задача имеет свой статический приоритет, причём двух задач с одинаковыми приоритетами быть не может. Планировщик задач выбирает для запуска задачу с наивысшим приоритетом из тех, что находятся в состоянии готовности (то есть, в принципе, допустима ситуация, когда какая-то задача ни разу не получит управления). Процессорное время выделяется задачам квантами, длительность кванта может варьироваться. Увеличение длительности кванта ухудшает параллелизм, но снижает затраты, связанные с переключением процессов; уменьшение длительности, соответственно, - наоборот.Для каждой задачи оптимальное значение длительности кванта будет своим, поэтому возможность настраивать длительность кванта времени весьма полезна. Также ОС должна предоставлять базовые функции по управлению процессами и реализацию основных примитивов синхронизации и межзадачного взаимодействия.
В данной статье мы рассмотрим функциональность разработанной системы и её возможности. В разделе 2 будет описана собственно сама операционная система и предоставляемые ей функции. Раздел 3 описывает доработки в интерфейсе интегрированной среды и отладчика MetaDSP, позволяющие создавать и отлаживать многозадачные приложения.

В настоящей работе была рассмотрена

В настоящей работе была рассмотрена операционная система реального времени MicroDSP-RTOS, разработанная в ИСП РАН для одного из индустриальных партнеров. Данная система предназначена для обеспечения работы многозадачных решений на базе «системы на чипе» c архитектурой MicroDSP. Реализация MicroDSP-RTOS выполнена полностью на языке ассемблера указанного микропроцессора с предоставлением прикладных интерфейсов для программ на языке C. Были рассмотрены основные возможности системы, этапы её развития, особенности поддержки отладки многозадачных приложений в интегрированной среде кросс-разработки.
Разработанная система имеет следующие характеристики (для времени выполнения указывается максимально возможное время; для перевода в микросекунды рассматривается процессор с частотой 200 МГц):

размер ядра	829 слов
полный размер системы (включая опциональные модули)	1957 слов
время сохранения/восстановления контекста	65 тактов (0,33 мкс)
длительность ISR (8 задач)	474 такта (2,37 мкс)
длительность ISR (63 задачи)	2290 тактов (11,5 мкс)

К настоящему моменту работа над MicroDSP-RTOS завершена, результаты внедрены в производство заказчика; в частности, известно о сотовом телефоне, в котором используется данная система.

Что такое виртуальная машина и зачем она нужна?

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

Задействованные виртуальной машиной ресурсы или "вырезаются" из основного пула ресурсов (как, например, происходит с оперативной памятью), или раздельно используются и хост, и виртуальной системами - как это происходит с процессором и съемными носителями.

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

Итак, поехали.

При инсталляции системы настройте видеопараметры X-Windows любым произвольным образом - инсталляция vmware-tools все равно все сделает по-своему.

Завершите инсталляцию и войдите в систему в консольном режиме с правами root.

Выйдите из виртуальной машины в хост-систему по <Alt + Ctrl> и выберите в меню Settings > VMWare tools install. В появившемся диалоговом окне (смысл вопроса в этом окне - "убедитесь, что вы запустили виртуальную машину") ответить Install. По этой команде виртуальная машине "вставит" в устройство лазерного диска /dev/cdrom (или как бы он там не назывался) образ диска со своими утилитами.

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

cd / mount -t 9660 /dev/cdrom /mnt cp /mnt/* /tmp umount /dev/cdrom cd /tmp tar zxf vmware-linux-tools.tar.gz (я делаю tar zxf vm*) cd vmware-linux-tools ./install.pl

При инсталляции следуйте поставленным вопросам - точнее, в нужных местах вставляйте <Enter>.

После инсталляции vmware-tools автоматически настроит разрешение и глубину экрана виртуальной машины аналогично параметрам хост-системы. Это не всегда удобно, а точнее - всегда неудобно, потому что окно виртуальной машины полностью покрывает все рабочее поле. Чтобы исправить такое положение, просто исправьте файл настроек X-сервера - для Red Hat и четвертых иксов это /etc/X11/XF86Config-4. Проигнорировав секцию Monitor (она больше ничего не делает) исправьте в секции Screen подсекции Display, указав вместо разрешения по умолчанию желаемое.

Если у вас все время слетает настройка, то просто автоматизируйте все перечисленные процессы, начиная с пункта 4 (конечно, копировать и разархивировать каждый раз не нужно). То есть инсталлируйте tools, исправляйте XF86Config и запускайте startx в одном стартовом скрипте уровня системы и/или пользователя. Для исправления XF86Config проще всего сохранить правильный вариант и потом просто делать cp.

Хочу обратить ваше внимание на то, что без установленных vmware-tools система тоже понимает какие-то режимы видео, в частности текстовые и графический VGA, так что даже если vmware-tools не устанавливаются на вашей виртуальной системе - это не значит, что она не будет работать. Яркий пример - Plan9, которая прекрасно работает без всяких vmware-tools, чем еще раз подтверждает, что в лаборатории Bell не разучились писать оси.

Какие операционные системы будут работать в VM?

Не существует однозначного ответа на этот вопрос - можно сказать только, для каких операционных систем виртуальная машина прошла тестирование. В принципе, если ОС работает на архитектуре Intel и не вытворяет с аппаратной частью несусветных вещей, то она с максимальной вероятностью установится и станет работать. Совершенно достоверно работают все версии DOS и Windows, а также основные дистрибутивы Linux. Проявив определенную настойчивость, мне удалось настроить FreeBSD (проблемы были только с видео, остальное прошло нормально). Определенно работает Plan9 (на VMWare). QNX работает в ограниченных графических режимах.

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

Настройка производительности

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

Например, для нормальной работы Windows 2000нужен (для ваших целей - в зависимости от того, что вы там гоняете) Pentium II/III 600. Для работы вашего Linux-сервера в терминальном режиме требуется Pentium 300. Просто складывая эти числа, вы получите искомый 1 ГГц, на котором обе системы будут поддерживать прежнюю производительность.

В меню Settings > Preferences на закладке Priority VMWare есть установка приоритетов, помогающая тонко настроить приоритет вашей виртуальной машины при распределении циклов процессора. Global обозначает настройку для всех виртуальных машин. Локальная настройка относится только к текущей виртуальной машине. Grabbed input соответствует режиму, когда виртуальная машина получает управление и захватывает ввод пользователя; Ungrabbed, соответственно,- фоновому режиму виртуальной машины (даже если ее окно и находится на переднем плане).

Особое внимание нужно обратить на память, учитывая, что она выделяется статически, в момент запуска виртуальной машины. Поскольку на хост-системе установлена виртуальная память, можно загрузить несколько виртуальных машин - и под все будет распределена память. Но поскольку вся она (на 90%) будет в файле подкачки, производительность упадет драматически. Рассчитывайте память честно, беря в расчет только физическую память. Например, современные Linux-системы с Gnome для комфортной работы требуют около 128 Мб памяти. Плюс в хост-режиме под NT5 вы планируете обрабатывать графику (как я, например, обрабатываю скриншоты), что, по моим оценкам, тоже требует около 128 Мб. Добавьте сюда еще несколько приложений, таких как браузер, почтовый клиент, текстовый редактор. Таким образом, система с 256 Мб будет показывать несколько замедленную реакцию в требовательных к памяти приложениях, а вот установка 256 + 128 Мб обеспечит полный комфорт в работе.

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

Настройка видеопараметров и установка vmware-tools

Настройка видео - ответственный участок в настройке виртуальной машины. По крайней мере, при настройке X-Windows - поскольку тут придется сделать кое-что своими руками. VMWare и VirtualPC решают проблему видео разными путями, а именно: VirtualPC эмулирует видеокарточку S3 Trio 32/64 PCI, и поскольку любая существующая операционная система поддерживает эту карточку с вероятностью 99,99%, то таким образом проблема видео решается удовлетворительно.

Совершенно другим путем пошла VMWare. Вместо эмуляции какой-то существующей карточки она предлагает собственный драйвер, входящий в пакет vmware-tools, устанавливаемый на виртуальной системе. Поскольку процесс в некотором смысле "магический", то я его опишу здесь детально на примере установки под Red Hat Linux. С небольшими отличиями это применимо и для других версий Linux и BSD.

Семь вещей, которые нужно знать о VMWare и VirtualPC

Арсений Чеботарёв, Издательский Дом "КОМИЗДАТ"

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

Типичным вопросом, который задают тысячи (а не задают, но мучаются им, миллионы) пользователей, программистов и администраторов, звучит примерно так: "Я не против попробовать Linux (FreeBSD, Plan9, Solaris, QNX), хотел бы поставить его на свой компьютер, испытать в работе. Но для этого нужно как-то разбить свой жесткий диск, установить менеджер загрузки, перегружать все время компьютер… А как быть с сетью? - у меня дома нет сети, как мне освоить все сетевые возможности?" - ну и так далее.

Одно из решений - установить Cygwin и другие интересующие порты, о чем я напишу когда-нибудь. Ну а сегодня речь совсем о другом, о настоящих произведениях программистского ремесла - виртуальных машинах VMWare и VirtualPC.

Управление жесткими дисками и работа со сменными носителями

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

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

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

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

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

Под VirtualPC все сделано слабее. Сменные носители монтируются, подобно тому как это происходит в Unix. После того как диск примонтирован, он захватывается ВМ и из других систем не доступен. Если пользователь извлекает носитель, устройство автоматически освобождается - и ВМ теряет его. С этим был связан кошмарный глюк, над которым я бился добрых пять секунд: при инсталляции двухдисковой инсталляции, например ASP Linux, после установки первого диска я вставил второй, но система отказывалась его видеть. Смысл оказался в том, чтобы щелкнуть правой кнопкой на маленькой пиктограмме в строке состояния и снова захватить CD ROM.

Установка сети: есть из чего выбирать, главное не запутаться

Настройка сетевых интерфейсов - это самое важное, поскольку вряд ли кто-то ставит FreeBSD или Linux с иной целью, чем задействовать сетевые возможности последних. Представляемые виртуальные машины имеют несколько принципиально различных методов подключения к вашему компьютеру и ко внешней сети. Рассмотрим (как более канонический вариант) схемы подключения vmware и потом перечислим отличия в VirtualPC.

Существует три основных режима подключения виртуальной машины к сети: Bridged mode, NAT и Host Only, схематически показанные на рисунке.

Bridged mode дает виртуальной машине непосредственный доступ к внешнему интерфейсу хост-машины, на котором виртуальная машина самостоятельно устанавливает или получает через DHCP собственные сетевые параметры - такие как IP-адрес, маршрутизатор по умолчанию и тому подобные. Этот вариант подключения нужно использовать для тех случаев, когда на VM вы устанавливаете серверы, которые должны иметь определенные сетевые адреса.

NAT использует трансляцию адресов исходящего трафика. Напомню, что в этом случае адрес виртуальной машины, полученный по встроенному в NAT DHCP, в момент пересылки на внешний протокол подменяется на адрес хост-машины. При этом запрос помещается в таблицу запросов. Полученные ответы от удаленных систем сверяются с этой таблицей - и по ряду параметров находится соответствие, по типу "в ответ на ваше письмо от такого-то какого-то рады вам сообщить…". При пересылке в VM адрес снова подменяется, так чтобы программа, запросившая информацию, получила пакеты на свой порт и адрес. Таким образом пересылаются запросы и в серверные приложения, к которым пользователь обычно не обращается напрямую, например DNS.

NAT без проблем работает на исходящем трафике, но в случае входящего запроса все запросы приходят на адрес хост-машины, поскольку во внешнем мире все NAT-адреса были представлены одним адресом хост-системы. Для того чтобы виртуальная машина могла получать входящий трафик, на хост-машине необходимо вручную установить правило ретрансляции, смысл которого примерно следующий: "входящие пакеты на порту таком-то переводить в ВМ такую-то на порт такой-то (порт обычно тот же самый)".
То есть доступ к серверу можно осуществлять и через NAT, но это требует дополнительной настройки. Для более подробной инструкции по настройке NAT под VMWare ищите "Understanding NAT" в справочном пособии и изучайте файл C:\WINNT\system32\vmnetnat.conf.

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

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

Пару слов о VirtualPC, которая "тоже ВМ". Настройки здесь слабее, но, в общем, то же самое. Первый режим - None, никакой сети. Зачем он нужен - большая тайна Connectix. Второй режим - NAT, но, в отличие от VMWare, здесь никакой настройки не предусматривается, так что "A guest PC using Shared Networking is not able to act as an Internet server". Кроме NAT, есть еще режим Virtual Switch, что наиболее точно соответствует Bridged mode в VMWare. То есть виртуальная машина имеет свой собственный IP на внешнем интерфейсе хоста, со всеми вытекающими последствиями. У этого режима есть дополнительный фильтр, который ограничивает хождение пакетов "только между ВМ", "ВМ и хост" и "только наружу". При всей фантазии я не смог придумать этим фильтрам какого-то применения, так что оставляю это читателям в качестве лабораторной работы.

Вопрос последний, который возникает первым: "Как мне выйти из этой виртуальной машины?"

В VMWare нажмите левые <Alt + Ctrl>, в VirtualPC - правый <Atl>. Эти же комбинации вернут вас к хост-системе из полноэкранного виртуального режима. Другое дело - как вообще вернуться из виртуального компьютерного мира в реальную жизнь, но для этого клавишной комбинации пока не предусмотрено.

document.write('');

This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009

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

Ни для кого не секрет, что в нашей компании осуществляется по самым доступным ценам на сегодняшний день в Москве.

---

---