Журнал LinuxFormat - перейти на главную

LXF150:ChorusOS

Материал из Linuxformat
Перейти к: навигация, поиск

Содержание

ChorusOS: «Альтернативная история» UNIX

Роман Ярыженко перелистывает малоизвестные страницы истории *nix-систем.


Если попросить назвать микроядерную операционную систему реального времени для встраиваемых систем, известную годов с 80-х, читатель, скорее всего, ответит «QNX» – и будет прав. Но... лишь отчасти. Помимо QNX, была и, думается, и по сей день где-то применяется еще одна микроядерная ОС реального времени с открытым исходным кодом (публикуется под четырьмя открытыми лицензиями – GPL, SPL Lite, MPL и FreeBSD), ныне незаслуженно забытая. Некоторые даже считают, что QNX является подражанием данной ОС. Имя ей – ChorusOS.

История

О ранних версиях ChorusOS – тогда еще просто Chorus – удалось найти не очень много информации. Начало разработки проекта датировано 1979 годом. Тогда он был исследовательским проектом INRIA – французского Института исследований в информатике и автоматике, из стен которого, в частности, вышел Scilab – свободный аналог Matlab.

Chorus-V0, прототип ОС, разрабатывался в 1980 – 1982 гг. на основе трех идей. Некоторые из них мы подробнее рассмотрим позднее, пока же просто перечислим:

  • Актеры [Actors]
  • Распределенные приложения
  • Маленькое ядро [Nucleus]

Эти идеи использовались и в более поздних версиях.

V0 была написана на интерпретирующем Паскале и запущена на 8086-м процессоре.

Chorus-V1 (1982 – 1984) уже не была прототипом и запускалась на кластере из компьютеров SM90, базирующихся на процессорах M68K. Компьютеры были соединены 10-мегабитной Ethernet-сетью. Код на Паскале компилировался.

Ядро V2 (1984 – 1986) по сравнению с V1 не очень изменилось – зато внешнее API, походившее на UNIX того времени, было значительно изменено: появились функции для работы с файлами и процессами. Тем не менее, это не был UNIX – разработчики Chorus стремились к модульности (которая в те времена в UNIX отсутствовала) и к возможности распределения ресурсов между компьютерами. Эта версия была, скорее, проходной.

А вот в V3, которую начали разрабатывать в 1987 г. на коммерческой основе в компании Chorus Systems, были реализованы и новые идеи. Так, например, данная версия была переписана на C++. Разумеется, C++ был совсем не тот, который мы знаем сейчас, но по тем временам ОС, написанные на объектно-ориентированном языке, были в новинку (да, к слову, таких и сейчас мало). Также система стала именоваться микроядерной. Странная это была микроядерность... но об этом чуть позже. Также была введена возможность динамической виртуальной памяти и подкачки [demand paging], расширены некоторые базовые концепции защиты.

На базе ядра Chorus-V3 было несколько вариантов поставки.

  • Chorus/Micro – голое ядро (занимало в памяти около 10 КБ) жесткого реального времени. Стоимость лицензии на разработку – 5000 долларов. На основе этого ядра даже была разработана ОС для суперкомпьютера Cray.
  • Chorus/ClassiX – уже полноценный «конструктор» ОС со средой разработки.

Здесь необходимо дать некоторые пояснения. ОС и приложения для встраиваемых систем, естественно, никак не могут разрабатываться на результирующих [target] системах. Соответственно, для разработки необходима рабочая станция с соответствующим набором приложений. Но ведь на ней тоже должна стоять операционная система! В терминологии разработчиков встраиваемых систем она называется “host”. Так вот, Chorus/ClassiX в качестве Host-систем поддерживал UnixWare, SunOS и Solaris. Стоимость лицензии на разработку варьировалась от 9000 до 25 000 (по другим источникам, 11 000) долларов, а стоимость лицензии на одно target-устройство составляла, в зависимости от функциональности, от 25 до 163 долларов для тысячи и более устройств.

  • Chorus/MiX – подсистема Unix System V на базе микроядра Chorus. Требовала лицензии USL/Novell. Системные вызовы System V транслировались в системные вызовы микроядра.

Ничего не напоминает? Да-да, Wine работает на подобном же принципе! Фактически, ранние версии Windows NT были основаны на похожей идее – Native API и подсистемы. К слову, в свое время эта реализация System V считалась одной из лучших в Европе.

  • Chorus/JaZZ – расширения реального времени Java на базе Chorus/ClassiX.
  • Chorus/COOL – вариант с поддержкой CORBA – стандарт написания распределенных объектно-ориентированных систем повышенной сложности. По сути, это надстройка над Chorus/ClassiX.

В сентябре 1997 г. компания Chorus Systems была куплена Sun Microsystems. Возможно, это будут и не связанные события, но данная ОС через пять лет после ее покупки умрет. В пользу этой версии говорит и то, что при покупке оттуда ушли ее старые разработчики (но Мишель Жьен [Michel Gien] и Марк Гийемон [Marc Guillemont] остались. После угасания ОС они даже попытаются ее реанимировать...). Но до угасания еще было далеко, и Sun успела выпустить еще несколько версий.

Sun по неизвестным причинам отказалась от поддержки Chorus/MiX. Вместо этого она сосредоточилась на развитии слоя Java. Помимо этого, компания начала поставлять несколько переработанную среду разработки Chorus/ClassiX под своим брендом – Sun Embedded Workshop.

В июне 1999 г. была выпущена ChorusOS 4. Было решено отказаться от прежнего наименования систем. К сожалению, у нас нет сведений о нововведениях четвертой версии. Но имеется информация о версии 4.0.1. В числе улучшений данной версии значатся:

  • Обновлен стек TCP/IP, портированный из FreeBSD 2.2.8.
  • Упрощено администрирование.
  • Улучшены функции high-availability.
  • Введена поддержка исключений C++.

А зимой 2001 г. Sun анонсировала ChorusOS 5 и следом же, летом 2002, открыв исходные коды, отказалась от поддержки ОС. Среди новых возможностей пятой версии отметим IPv6, NTP и POSIX-RT API – расширения POSIX для поддержки приложений реального времени.

В августе (нет-нет, не 44-го! 2002-го) бывшие работники Chorus Systems, Мишель Жьен и Марк Гийемон, основали компанию Jaluna с целью вдохнуть вторую жизнь в Chorus. По неизвестной причине – не исключено, что из-за плохого маркетинга – это оказалась гальванизация трупа. Где-то в 2005 г. компанию Jaluna купила VirtualLogix, которую, в свою очередь – о, неумолимые законы капитализма! – купила RedBend Software. Быть может, ChorusOS, под иным именем, используется где-то в глубинах этой акулы капитализма, а может, и нет – сие нам неведомо [возможно, на ее основе построен гипервизор для мобильных устройств VLX, – прим. ред.]. Если используется, то и пусть. А мы перейдем к описанию архитектуры этой достойной ОС.


Актеры, порты, LAP’ы...

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

В основе ChorusOS лежит микроядро, которое сами разработчики в ранних версиях называли Nucleus. Оно состоит из модулей kern (реализует API микроядра), pmm (Persistent Memory Manager; используется при функции Hot Restart, которую мы здесь рассматривать не будем – скажем лишь, что эта функциональность задействуется для уменьшения времени простоя в случае сбоя) и pd, необходимый для обмена данными между подсистемами.

Также в составе микроядра работает Core Executive, исполнительная система, которая обеспечивает... да много чего обеспечивает, в числе прочего – обработку исключений, управление потоками, управление актерами...

Что такое «актер» [actor]? Актер – «единица инкапсуляции ресурсов» (цитата из документации). Проще говоря, это другое название процесса UNIX, с одним отличием: актер может выполняться как в адресном пространстве пользователя (при этом, естественно, адресное пространство у каждого актера свое), так и в адресном пространстве ядра [supervisor adress space] – соответственно, адресное пространство общее. Непонятно в таком случае, почему ОС – микроядерная: драйвера тоже выполняются в режиме супервизора, судя по исходным кодам; но не нам спорить с Таненбаумом. Не исключено, что при написании «Сравнения» (“A Comparison of Three Microkernels”) работа с драйверами в Chorus была реализована иначе, но это кажется сомнительным. И во избежание путаницы будем считать ее микроядерной ОС.

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

LAP (Local Access Point) и LAPSAFE применяются для вызова функций, экспортируемых актерами режима ядра [supervisor actors]. Различие их в том, что LAPSAFE не поддерживает экспорт напрямую: ее возможности используются для функциональности Hot Restart. Поверх микроядра лежит иерархия драйверов с двумя фреймворками – DDI (Device driver interface; нужен для сообщения между слоями драйверов) и DKI (Driver/Kernel Interface; предоставляет сервисы микроядра, специфичные для драйверов). И фреймворки, и драйвера исполняются в режиме ядра.

Далее лежит слой C_OS с актерами C_INIT (инициализация), IOM (ввод/вывод) и ADMIN (используется для специфических функций администрирования).

Актер IOM используется для реализации совместимости с POSIX. Практически же, эта подсистема основана – на чем бы вы думали? – на FreeBSD 4! Да-да, вы поняли правильно – IOM, по сути дела, является ядром FreeBSD, запущенным как актер ChorusOS, опять же, в режиме ядра (возможно, частично – мы, к сожалению, не гуру по исходным кодам данной ОС).

Наконец, слой приложений – тут, думаем, все ясно. Доступны такие системные утилиты, как mount, chmod, route... и даже X11! Из-за ограниченной поддержки эффективного и реального UID не реализован бит SUID. Но – нужна ли подобная функциональность во встраиваемых системах?..

Увы, статья имеет ограниченный объем, поэтому мы вынуждены закругляться. Не были рассмотрены такие возможности, как Hot Restart, динамические библиотеки... но это неудивительно – ибо даже в книге по программированию в ChorusOS есть не все.

Итоги

ChorusOS была системой, оперед... стоп. Это уже где-то было. И все-таки – много ли микроядерных систем вышло за рамки лабораторий и имело хоть какой-нибудь коммерческий успех, пусть даже в специфической области встраиваемого оборудования? Так или иначе, ChorusOS не добилась большой известности, оставаясь в тени своей кузины QNX, и, возможно, потому и увяла. Но вдруг какой-нибудь студент университета напишет в список рассылки ChorusOS сообщение вида «Hello everybody out there using chorusos – I’m doing...»? Как знать...

Персональные инструменты
купить
подписаться
Яндекс.Метрика