> man operating_systems
Создавая новое поколение - часть 2
ОС
на Пятница, 22 Октябрь 2004, 00:36
добавил: Николас Блэхфорд (Nicholas Blachford) список авторов печатать элемент контента создать pdf-файл  элемент контента
категория Статьи
комментарии: 0
просмотров: 2453

В этой серии рассматриваются некоторые технологии, которые мы могли бы применить, если бы сегодня создавали новую платформу. В <a href=http://www.osrc.info/content.php?article.60>первой </a> я описал систему с многоядерным многопоточным ЦП, процессоры FPGA и Cell. В этой, второй части, мы начнем рассматривать операционную систему.<br /><br />
Перевод: Роман Химов aka Roman I Khimov <br />
<a href=http://www.osnews.com/story.php?news_id=7703>Оригинал </a> доступен на OSNews.com.

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

Единственное, она не должна быть похожа на Unix. Именно так, это должна быть НЕ Unix. Сколько нам нужно версий Unix? Если вы хотите настольную, берите OS X, хотите серверную - скорее всего подойдет любая версия Unix. Если вы хотите "" - берите Linux или BSD, в зависимости от того, какая Свобода вам больше нравится, если вам нужна Безопасность, держите OpenBSD. Существуют вариации Unix для практически любых задач, и это даже до того, как вы начнете просматривать дистрибутивы Linux. Неужели нам действительно нужен еще один Unix?

Я бы гораздо больше предпочел что-нибудь новое, что-то, что сможет использовать преимущества новых технологий и использовать лучшие возможности разных ОС. Проект Ruby OS (ROS) даже ведет онлайн-страницы, где они собирают лучшие идеи [RubyList].

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

Существуют много вариантов операционных систем на выбор, но я бы остановился на Haiku, поскольку она исходит от BeOS, а значит будет отлично работать со множеством процессоров и множеством потоков, а также у нее нет множества наследственных проблем, а значит не надо будет делать обходных путей и не надо ничего крушить (в данном случае она всего лишь служит базой для новой ОС, а, значит, проблемы обратной совместимости могут быть полностью проигнорированы. Современный API и особое внимание к мультимедийным возможностям также будут плюсом, как и дружественная к коммерческим инициативам ультра-бесплатная лицензия MIT. Для любого коммерческого проекта, а этот проект больше похож именно на коммерческий по своей сути, вопросы лицензирования гораздо сложнее, чем могут себе предположить адвокаты и их рекомендации стоит выслушать очень внимательно [Licenses].

Что еще важно, так это тот факт, что Haiku, конечно же, будет по своей структуре схожа с BeOS, а из этого следует то, что она будет "микроядерного ". Однако, я это изменю, вынося из ядра все что можно, так чтобы оно стало настоящим микроядром [Micro]. С технической точки зрения, ядро фактически превратится в экзоядро [Kernel], однако система будет работать как микроядерная ОС.

Микроядерные системы используются в системах жесткого реального времени и системах высокого риска (то есть там, где системная ошибка вполне может кого-нибудь убить). Жесткое реальное время и пуленепробиваемя стабильность - хорошие характеристики и хорошая цель, однако настоящие микроядра практически никогда не используются в коммерческих настольных системах, где позже они часто модифицируются и становятся "микроядерного ", когда некоторые части переносятся в ядра (например, графика в Windows NT, сетевые возможности в BeOS-Dano).

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

Почему не Linux?

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

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

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

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

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

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

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

индекс статьи
страница 1 - текущая : страница без заголовка
страница 2 : страница без заголовка
страница 3 : страница без заголовка


© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.