Центр информации по операционным системам: Новости / Комментарии / Проект Xameleon

Что такое Xameleon? Это микроядерная операционная система построенная на базе L4Ka::Pistachio.

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

[Прислал alman]

Roman I Khimov в Суббота, 28 Октябрь 2006, 10:37 |

Комментарии: 50 |

Комментарии

Roman I Khimov \|28.10.2006 10:46
Комментарии: 952	Чем это отличается от того, что делает TUD или NICTA?

ddc \|28.10.2006 11:17
Комментарии: 523	Какой же кривой сайт у этого Xameleon'а... Специально посмотрел, из всех домашних компьютеров только машина с WinXP смогла отобразить это так, чтобы можно было смотреть без содрогания, и то лишь через IE...

Dreamer \|28.10.2006 18:14
Комментарии: 347 Зарегистрирован: 04.07.2004 14:01	М-да... В факах девелопер явно себя не обидел. Особенно фак номер 20 А вообще, что-то попахивает чем-то под названием "еще один".

alman |28.10.2006 22:30

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

> Чем это отличается от того, что делает TUD или NICTA?

TUD - базируется на Fiasco, разработке Дрезденского университета. Что круче, Pistachio или Fiasco - тема для holywar. Я пробовал оба микроядра. Мой выбор - Pistachio.

NICTA, насколько мне известно, делает свою разработку на базе технологии Corba. Кстати, я не уверен, что их микроядро не есть форк pistachio на тему процессоров arm. Но могу и ошибиться.

alman |28.10.2006 22:36

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

> Какой же кривой сайт у этого Xameleon'а... Специально посмотрел, из всех домашних компьютеров только машина с WinXP смогла отобразить это так, чтобы можно было смотреть без содрогания, и то лишь через IE...

проверял только IE и links. Вроде, оба отображали нормально. Правда, при разрешении 1024x600 получается полный бред.

К сожалению, у меня нет таланта WEB дизайнера. Ещё более жаль что не хватает на всё времени. Может быть к осени сайт переделается. Пока свободное время уходит на напсиание кода и отладку.

alman |28.10.2006 23:11

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

М-да... В факах девелопер явно себя не обидел. Особенно фак номер 20

Согласен, глупый вопрос 20. Уберу, когда в следующий раз буду редактировать.

А вообще, что-то попахивает чем-то под названием "еще один".

Предлагаете меряться пис-ми?
Хотя, формально - да, ещё один.

alman \|29.10.2006 05:45
Комментарии: 58 Зарегистрирован: 28.10.2006 01:21	В факах девелопер явно себя не обидел. Особенно фак номер 20 Номер двацать переписан. Возможно, он будет Вам интересен. Что ещё Вам не понравилось?

captain cobalt \|29.10.2006 08:44
Комментарии: 83 Зарегистрирован: 04.07.2004 21:44	У меня тоже вопрос для FAQ Зачем сейчас нужны микроядра, если монолиты нынче столь надёжны что практически все уязвимости располагаются на прикладном уровне?

Dron |29.10.2006 10:39

Комментарии: 558

Вот это точно тема для холивар.

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

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

alman |30.10.2006 00:53

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

Зачем сейчас нужны микроядра, если монолиты нынче столь надёжны что практически все уязвимости располагаются на прикладном уровне?

Если коротко, то в этом споре больше доверяю Таненбауму, чем Торвальдсу

Если развёрнуто...
Систему на микроядре легче разрабатывать, отлаживать, поддерживать и расширять.
Например, файловая система Xameleon писалась и отлаживалась под Windows в среде Visual Studio, затем код был портирован под Xameleon. Не спорю, таким образом можно отлаживать и части монолитной системы, но при таком подходе трудозатраты будут несоразмерно выше.

Систему на микроядре легче масштабировать. Потоки обмениваются сообщенияим - никаких прямых вызовов. Причём, потоки могут быть в одном адресном пространстве, разных адресных пространствах, на разных ядрах/процессорах и даже на разных машинах. Что это даёт? Во первых, вы можете запускать один и тот же код как в контексте Supervisor, так и в виде самостоятельного процесса. В первом случае вы получаете скорость, которая будет ничуть не ниже чем в монолите, а во втором случае получаете стабильность.

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

Помимо этого, микроядерные системы навязывают другой подход к реализации системы.
По сути, микроядерную систему можно представить как множество сервисов, которые реализованы в программных потоках, обменивающихся сообщениями. Большую часть времени все потоки находятся в состоянии ожидания. Одни потоки ждут пользоваельской рекации, другие ждут запроса от пользовательских процессов и ответов от оборудования. Поскольку IPC в Pistachio синхронны, а работа сервисов и драйверов асинхронна, это накладывает определённые требования на реализацию сервисов. В данном случае целесообразно использование конечных автоматов. Что даёт использование конечных автоматов? Во первых, реализация асинхронности, в вторых, совместно с синхронными IPC - автоматическую защиту данных от доступа из несколькиъ потоков.

Спасибо за то, что дочитали до сюда.

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

Извините за многословность и опечатки.

captain cobalt \|30.10.2006 04:18
Комментарии: 83 Зарегистрирован: 04.07.2004 21:44	А каковы перспективы собственной среды разработки? Звучит устрашающе: перезагрузить в винду, компилировать в msvc, перезагрузить в систему, посмотреть что получилось, повторить.

ddc |30.10.2006 12:02

Комментарии: 523

alman написал(а) ...
проверял только IE и links. Вроде, оба отображали нормально. Правда, при разрешении 1024x600 получается полный бред.

К сожалению, у меня нет таланта WEB дизайнера. Ещё более жаль что не хватает на всё времени. Может быть к осени сайт переделается. Пока свободное время уходит на напсиание кода и отладку

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

captain cobalt написал(а) ...
Зачем сейчас нужны микроядра, если монолиты нынче столь надёжны что практически все уязвимости располагаются на прикладном уровне?

Ответ: затем, что микроядро эстетически правильней и проще (я не понимаю, о каком усложнении в IPC говорит Торвальдс), а значит новой ОС оно придаёт большую изначальную стабильность, старой - элегантность.

captain cobalt |30.10.2006 13:21

Комментарии: 83

Зарегистрирован: 04.07.2004 21:44

ddc написал(а) ...
микроядро эстетически правильней и проще

Оно не только проще, но и умеет гораздо меньше.

Если же взять монолит и эквивалентный объём функциональности на микроядре, то решение на микроядре не проще. Хорошо?

ddc написал(а) ...
я не понимаю, о каком усложнении в IPC говорит Торвальдс

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

Если мы хотим наладить взаимодействие между несвязанными пространствами, то дополнительно понадобится:
-- создавать и закрывать объекты IPC
-- маршаллить данные от клиента
-- парсить данные на стороне сервера
-- страшные и ужасные "переключения контекста" завершают картину.

Dron \|30.10.2006 17:01
Комментарии: 558	А никто и не говорил, что микроядро - это быстро... Микроядро - это надежно... вместо страшной и ужасной прямой передачи управления - защищенные вызовы. маршаллинг и парсинг - это не самые страшные слова.

captain cobalt |30.10.2006 17:36

Комментарии: 83

Зарегистрирован: 04.07.2004 21:44

Пользователям не нужно надёжное микроядро.
Пользователям нужна надёжная система.

Над микроядром в сервисах и приложениях остаётся полный набор уязвимостей:
-- переполнения буфера
-- sql-инъекции
-- xss
-- и т. д.

Это более 90% проблем информационной безопасности.

Микроядро решает менее 10% проблем.

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

Dron |31.10.2006 07:32

Комментарии: 558

А это все из за монолитности приложений...

Хотя конечно на 100% от ошибок не застрахован никто.

Просто приоритеты программирования смотрят не в ту сторону.
Надо думать о надежности а не о фичах.

Сейчас все кому не лень со спокойной душой выпускают дырявое ПО. ИМХО - преступление.

Brain \|31.10.2006 10:42
Комментарии: 12 Зарегистрирован: 10.11.2005 09:04	Ситема не OpenSource?

ddc |31.10.2006 17:48

Комментарии: 523

captain cobalt

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

Что касается уязвимостей, тут вообще не понимаю, о чём речь. Есть монолитное ядро, которое имеет модули и интерфейсы. Есть микроядро, в котором вместо этого хозяйства используется IPC. IPC труднее сделать безопасным? Допустим. Но только (1) не бывает систем, где исполняется только ядро, и при подвисании пользовательского процесса из-за уязвимости IPC систему придётся уводить в shutdown даже при рабочем ядре, т.е. даже самое стабильное и безопасное ядро не спасает от проблем с IPC, (2) всё равно часть модулей фактически является мостом между ядром и отдельными процессами, т.е. проблема влияния безопасности IPC на стабильность ядра не исчезает, и (3) наконец следить за безопасностью IPC и безопасностью транзакций в ядре сложней, чем за одним IPC.

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

ddc \|31.10.2006 17:49
Комментарии: 523	Brain В FAQ всё написано.

alman |02.11.2006 22:46

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

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

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

Если мы хотим наладить взаимодействие между несвязанными пространствами, то дополнительно понадобится:
-- создавать и закрывать объекты IPC

Эти вещи успешно решил профессор Leidke, который математически обосновал преимущества подохода Lazy Scheduling. К сожалению, Leidke умер. но несколько университетов по всему миру решили воплотить его идеи в жизнь, чтобы доказать теорию. Мне кажется - у них не плохо получается.

-- маршаллить данные от клиента

Посмотрите как это сделано в L4. Ключевое слово - синхронные IPC. Маршаллинг понадобится только для удалённых процессов, у которых нет общей физической памяти.

-- парсить данные на стороне сервера

У меня возникает желание открыть код, чтобы показать как красиво это может быть.

-- страшные и ужасные "переключения контекста" завершают картину.

А вот это боль. Впрочем, боль уходит когда вспоминаешь спинлоки. Вы знаете для чего нужны и как работают спинлоки в критичесих секциях систем Linux и Windows?

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

Кстати, я рассматриваю проблему переключения контекста как временную. Будущие поколения микропроцессоров должны переключать контекст быстрее. В идеале - системные вызовы L4 могут быть реализованы в железе.

alman \|02.11.2006 23:07
Комментарии: 58 Зарегистрирован: 28.10.2006 01:21	ddc Если хотите, могу скинуть своё видение того же дизайна, но без истязания зрителей отображающегося в любом браузере. Очень хочу. Буду признателен.

alman |02.11.2006 23:34

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

А каковы перспективы собственной среды разработки?

Звучит устрашающе: перезагрузить в винду, компилировать в msvc, перезагрузить в систему, посмотреть что получилось, повторить.

Cейчас для сборки используется gcc под Слакварью, которая живёт в MS Virtual PC. На слаке стоит Samba, которая отдаёт домашнюю директорию Xameleon по SMB. Эта директория смонтирована в Windows как логический диск. Xameleon отлаживается на втором виртуальном PC. Сырцы правятся в Visual Studo, компилится всё под Linux. Так что перегружать приходится только один виртуальный компьютер.

Roadmap такой - первым делом предстоит пофиксить ошибки, коих множество. Затем добавить в libc несколько функций, чтобы для успешной сборки busybox. Затем предстоит портануть gcc.

По моим понятиям, среда разработки должна быть графическая (хей, BorlandC:), а прикручивать графику к Xameleon на данном этапе означает попросту растрачивать силы.

Есть вероятность что раньше графики появится TCP/IP стек. Тогда уже можно думать о NFS серверере или портировании Samba.

captain cobalt |03.11.2006 07:34

Комментарии: 83

Зарегистрирован: 04.07.2004 21:44

alman написал(а) ...
Это бесспорно.
Однако, в связи с появлением многоядерных микропроцессоров, время одного адресного пространства постепенно уходит.

Непонятно что это значит.

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

DLL в одном адресном пространстве должны уйти в прошлое?

alman написал(а) ...
У меня возникает желание открыть код, чтобы показать как красиво это может быть.

Это также место для уязвимости.

Неправильно сформированные запросы должны надёжно обнаруживаться. Это будет гораздо менее красиво. Иначе - дыра в безопасности.

ddc \|03.11.2006 11:59
Комментарии: 523	alman написал(а) ... Очень хочу. Буду признателен. ОК. Сегодня вечером или завтра скину на support@l4os.info.

alman |04.11.2006 00:25

Комментарии: 58

Зарегистрирован: 28.10.2006 01:21

DLL в одном адресном пространстве должны уйти в прошлое?

Конечно нет.

Просто мы говорим немного о разных вещах - Вы о прикладном уровне, я о системном. На прикладном уровне всё остаётся по старому. Во всяком случае - внешне

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

Та же самая задача красиво решается при использовании синхронных IPC. Решается просто - каждым объектом владеет только один поток. Этот поток "слушает" запросы от других потоков. Методы и свойства объекта реализуются через синхронные IPC. Таким образом объекты взаимодействуют друг с другом. Объекттом может быть как и простейшая структура данных, так и сложный код, предоставляющий реализацию како-либо протокола.

Вот базовые понятия для такой реализии:
1. Каждая релизация протокола или драйвера устройства есть програмный поток или несколько потоков.
2. Такой поток называются фильтром.
3. Нексолкьо фильтров образуют конвеер.
4. Фильтры асинхронны с той точки зрения, что могут принмать следующий запрос, до выпронения предыдущих.
5. Исходя из пункта 4, фильтры внутри конвеера исполняются параллельно.
6.Развязка синнхроных вызовов в асинхронные протоклы реализуется посредством конечных автоматов.
7. Потоки могут мигрировать между процессорами/ядрами системы.

Неправильно сформированные запросы должны надёжно обнаруживаться. Это будет гораздо менее красиво. Иначе - дыра в безопасности.

http://www.l4os.ru/xam_dispatcher.cc.html

Это ссылка на код, который обслуживает вызовы задачи Supervisor.
В принципе, этот код есть не что иное как реализация интерфейса к некоторым объектам. Как видите, реализацию объектов я не показываю

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

В принципе, могу ещё выложить диспетчер для файловой системы.

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