О микроядрах

видимо нет заинтересованных компаний.

Насколько мне известно, в современных микроядрах, например L4, вопрос производительности решен.

Как?

вопрос производительности решен

«LOR style: ненужно», или как?

как то решили, подробности не изучал

как то решили

Само ядро сильно заоптимизировали, да. Все остальные проблемы остались.

«LOR style: ненужно», или как?

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

И оно активно используется.

Не сказал бы.

Но не в опенсорсных ОС.

Genode

Вот в том то и прикол. Само микроядро может быть сколь угодно быстрым, но проблему дорогого IPC это не решит.

Всяко SYSCALL + выполнение запроса + SYSRET (тоже не самая «легкая инструкция) выйдет бысрее, чем SYSCALL + смена контекста + SYSRET + выполнение запроса + SYSCALL+ смена контекста + SYSRET.

А если принепающая сторона запущена/запускается на другом ядре?

Монопольно и непрерываемо? Если нет, то и смена контекста никуда не уходит.
А если монопольно, ядер не хватит))

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

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

Вот в том то и прикол. Само микроядро может быть сколь угодно быстрым, но проблему дорогого IPC это не решит.

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

Why?

Очень правильный вопрос. Нахрена оно нужно? Какие практические задачи решит, какие профиты даст? Правильно, никаких.

Микроядра позволяют разбить функциональные узлы ОС по изолированным модулям. Монолитное ядро — это все равно что god object в ООП.

минимизирован

Но он есть и остается.

L4Linux (паравиртулизированный) в некоторых тестах немного опережает нативный

В некоторых тестах Linux опережает Linux, т.к. в нем постоянно что-то меняют, переписывают и т.д. И далеко не всегда более новая версия опережает более старую.

Но он есть и остается.

И что?!

В некоторых тестах Linux опережает Linux, т.к. в нем постоянно что-то меняют, переписывают и т.д. И далеко не всегда более новая версия опережает более старую.

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

cast alexst

Вопрос производительности решён.

вопрос производительности IPC. тот же сетевой стек всех существующих реализаций L4 не выдерживает никакой критики

тот же сетевой стек всех существующих реализаций L4 не выдерживает никакой критики

L4 не содержит никакого сетевого стека и содержать по определению не может, иди спи.

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

В не-опенсорсных не очень знаю как. У Qualcomm в AMSS (фирмварь на модемном ядре), конечно, L4 Pistachio от NICTA. Но там какой-то производительности не надо - по сути, эта фирмварь - всего лишь для контроля доступа к регистрам железа. А всякая мультимедия сделана через огромный кусок общей памяти между двумя процессорами. В коммереских (General Dynamics) виртуальных линуксах на телефонах вроде ядра sel4.verified и codezero. Думаю, там просто вопрос производительности остро не стоит

Вот дебажили сеть на Genode. Это такой фреймворк для создания программ на микроядрах. Ядро Fiasco.OC. Сеть тормозит. На отдачу - 600 мбит, а на прием - 10. Я так и не нашел, в чем дело, но основные затраты там были не на копирование памяти, а на IPC вызовы. Разработчики из Genode решили переделать сеть, свести к минимуму количество тредов-обработчиков

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

а где эти тесты можно посмотреть?

Ну самый сверическое и вакууме тут: http://ertos.nicta.com.au/news/home.pml#v-gt-r

поэтому не копируется память буфера IPC - он один раз мапится.

Копирование есть, только не два раза, как в Mach, а один.

А какие есть популярные микроядерные ОС кроме Symbian и QNX?

вопрос производительности

Тут гуй на js пишут, а микроядро видите ли тормозит!

«LOR style: ненужно», или как?

Шйорт побьяри, я угадал: http://ru.wikipedia.org/wiki/Mach#.D0.A1.D0.BB.D0.B5.D0.B4.D1.83.D1.8E.D1.89....

Тут гуй на js пишут, а микроядро видите ли тормозит!

Если ты про Qt, то сильно не прав. Там за каждой операцией в js стоит дергаемый C++ код. Всё пашет довольно шустро.

Там за каждой операцией в js стоит дергаемый C++ код

Можно подумать, что другие интерпретаторы работают иначе.

Можно подумать, что другие интерпретаторы работают иначе.

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

Ага, и в лазанье, которую представляют современные операционные среды.

Микроядра позволяют разбить функциональные узлы ОС по изолированным модулям.

Верно с одним уточнением - по _аппаратно_ изолированным модулям (не будем вдаваться в детали rogue DMA). Но просто для протокола: изоляция не обязана быть аппаратной.

Монолитное ядро — это все равно что god object в ООП.

Чушь и/или троллинг.

Займись. Мы ждём.

Верно с одним уточнением - по _аппаратно_ изолированным модулям

ну вот это и создает в микроядрах интересные свойства, например, позволяет создать очень маленькую часть, которой необходимо доверять (в разных контекстах может быть Reliable computing base или Trusted computing base). Что в монолитных ядрах сделать нельзя в принципе.

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

Вот, например, функция, которая в линуксе только появится, а в Hurd (да и в других микроядерных системах) была изначально: http://lwn.net/Articles/550555/

Amoeba

под словом «популярная» я имел в виду миллионов сто установок а не штук сто.

Когда я это спросил, Ttt просто сказал, что «это же микроядро!11». Подпишусь на тему.

Верно с одним уточнением - по _аппаратно_ изолированным модулям

ну вот это и создает в микроядрах интересные свойства

...на практике не особо нужные.

Reliable computing base или Trusted computing base

Насчет reliable - это может достигаться и программными средствами; насчет TCB - первая система, сертифицированная на EAL5 - монолитная (http://en.wikipedia.org/wiki/XTS-400), да и вообще связь между микроядерностью и минимальностью TCB туманна.

в современном аппаратном обеспечении растет вероятность аппаратных ошибок

...и поэтому нужно полагаться именно на аппаратную защиту? Неожиданный вывод.

под словом «популярная» я имел в виду миллионов сто установок

Ходят слухи, что seL4 установлен в миллиардах устройств. Правда, эксперты ЛОР считают, что не в роли ОС, а в роли гипервизора.

Насчет reliable - это может достигаться и программными средствами; насчет TCB - первая система, сертифицированная на EAL5 - монолитная (http://en.wikipedia.org/wiki/XTS-400),

Если мы говорим о безопасности или об устойчивости к программным ошибкам (багам), то большая TCB всего лишь значит, что доказать безопасность системы сложнее, чем в случае с маленькой. Размер TCB имеет принципиальное значение, если речь идет об устойчивости к аппаратным ошибкам. И вот тут у микроядер потенциал больше.

, да и вообще связь между микроядерностью и минимальностью TCB туманна.

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

...и поэтому нужно полагаться именно на аппаратную защиту? Неожиданный вывод.

На самом деле никакого противоречия нет. Если TCB маленькая, то вероятность, что любая, в том числе аппаратная, ошибка появится в TCB — меньше.

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

Каким образом микроядро уменьшает размер TCB (именно TCB, не RCB)? Даже вынесенный из ядра драйвер остается частью TCB, то же самое и с файловой системой - ты вынужден полагаться на то, что они функционируют корректно. Возможно, _изоляция_ компонентов делает доказательство безопасности более простым, но размер TCB от изоляции не уменьшается.

Размер TCB имеет принципиальное значение, если речь идет об устойчивости к аппаратным ошибкам.

Если речь о живучести системы, то речь о RCB, а не TCB. Естественно, маленькая _изолированная_ RCB увеличивает живучесть системы, но мы снова возвращаемся к тому, что изоляцию можно обеспечивать разными способами.

Если TCB маленькая, то вероятность, что любая, в том числе аппаратная, ошибка появится в TCB — меньше.

А если [RT]CB не полагается на аппаратную изоляцию, то она вообще не зависит от ошибок в аппаратной изоляции.

Каким образом микроядро уменьшает размер TCB (именно TCB, не RCB)? Даже вынесенный из ядра драйвер остается частью TCB, то же самое и с файловой системой - ты вынужден полагаться на то, что они функционируют корректно. Возможно, _изоляция_ компонентов делает доказательство безопасности более простым, но размер TCB от изоляции не уменьшается.

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

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

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

Какими? Если это намек на Singularity, то там часть TCB является компилятор, а это очень большая часть системы, особенно учитывая, что компилятор должен уметь оптимизировать код и делать это быстро.

А если [RT]CB не полагается на аппаратную изоляцию, то она вообще не зависит от ошибок в аппаратной изоляции.

Тогда она зависит от других ошибок и не факт, что это сделает систему более устойчивой.

допустим у тебя есть верифицированный драйвер файловой системы, но в следствии своей простоты в нем нет никаких оптимизаций и он очень медленный. Тогда ты пишешь второй драйвер, который не верифицирован, но быстрый. Теперь для тех разделов, которые входят в TCB ты используешь первый драйвер, а для остальных — второй.

Не понял, что доказывается этим примером. Не говоря уже о том, что допущение вроде наличия «остальных разделов» выглядит натяжкой.

проблема монолитной системы в том, что не все привилегированные компоненты являются частью TCB и их трудно вынести из TCB. Например драйвер web-камеры

Это снова вопрос изоляции.

Если это намек на Singularity

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

то там часть TCB является компилятор, а это очень большая часть системы

Компилятор всегда является частью TCB.

если [RT]CB не полагается на аппаратную изоляцию, то она вообще не зависит от ошибок в аппаратной изоляции.

Тогда она зависит от других ошибок

Да, от программных ошибок. Но аппаратура, _вдобавок_ ко всем недостаткам программ, подвержена физическим дефектам и изнашиванию.

Ходят слухи, что seL4 установлен в миллиардах устройств. Правда, эксперты ЛОР считают, что не в роли ОС, а в роли гипервизора.

они и позиционируют свой продукт в первую очередь как гипервизор. сейчас еще идет подъем l4linux и genode и ЧСХ именно на мобильных устройствах.

Это снова вопрос изоляции.

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

Компилятор всегда является частью TCB.

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

И кто их поднимает на мобильных устройствах?