Почему разработка микроядер идёт так вяло.

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

Это никак не микроядро.

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

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

Сдается мне, что достоинства микроядра слегка преувеличены. Что у нас там в микроядре должно быть реализовано - планировщик, изоляция процессов, управление памятью, частично IPC. А все остальное (подсистема безопасности, ФС, сетевой стек, IPC и пр. и пр.) не становится «железобетонно» надежным автоматически только потому, что оно работает поверх супернадежного микроядра. Ну и в чем профит? Надежность системы определятся надежностью самого слабого её звена.

Монолитные ядра «в среднем» существенно быстрее.

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

У нас тут был Кайнокен, который почти в одиночку запилил полнофункциональную ось на микроядре. Им лично, с нуля, было написано вообще все кроме прикладного/пользовательского софта. С монолитом номер скорее всего бы не прошел.

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

Хотел вам разжевать всё про микроядро и вообще, про текущее состояние дел с ОС высокой надежности, разрабатываемых в подвалах SpaceX. Но невежественный мудак квазар засирает тему своими постами уровня 12-летней девочки, а лорчик с ним продолжает разговаривать.

вопрос знатокам: что будет если крахнется «вынесенное из ядра» управление памятью? а если спендикрючится драйвер файловой системы? микроядро не дает особых преимуществ и даже безопасности особой. оно позволяет упростить взаимодействие с userspace ценой некоторых потерь производительности

Сдается мне, что достоинства микроядра слегка преувеличены.

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

Хотел вам разжевать всё про микроядро и вообще, про текущее состояние дел с ОС высокой надежности, разрабатываемых в подвалах SpaceX.

разрабатываемых в подвалах

Это всё, что нужно знать про микроядра.

Но невежественный мудак квазар

Да ладно? Ну давай, расскажи всем, как в микроядрах решли проблоему накладных расходов на переключение контекста. Конечно не расскажешь, так как проблему не решили и не решат. Микроядра - это defective by design. Надёжность всей системы они не увеличивают, что тут выше только подтвердили.

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

Я где-то говорил, что я собирался спорить с тобой, недоумком?

ТСу

man IPC </thread>

я прямо восхищаюсь твоим мастерством аргументации. ты с мамкой также дерзко разговариваешь?

Я где-то говорил, что я собирался спорить с тобой, недоумком?

Офигенное описание преимуществ микроядра! Давай ещё!

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

От переключения контекста, не? Вам стоит подтянуть русский язык, рекомендую классическую русскую литературу — пользуйтесь тем, что владеете языком в достаточной мере.

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

Вопрос прежде всего к людям коммитящих в ядро или собиравших lfs\преподающих

Ты на ЛОРе, здесь других нет.

Лично меня напрягает, что где то над моей головой в 300 км, висит МКС управляемая Убунтой.

Расслабься, там win98.

Танненбаум - просто имбецильный рукожоп.

твой сосед по палате считает себя таненбаумом?

А можно ли хотя бы теоретически сделать так, чтобы падение части ядра не валило за собой всё ядро?

А можно ли хотя бы теоретически сделать так, чтобы падение части ядра не валило за собой всё ядро?

Разделить ядро на части и реализовать обмен инфой между частями по некоторому протоколу.

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

реализовать обмен инфой между частями по некоторому протоколу

Без этого нельзя?

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

в нектором смысле это равносильно контейнеризации каждого програмки в системе.

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

Так в том то и загвоздка. Что мне за радость в том, что надежное микроядро не упало, когда упал и не может подняться драйвер файловой системы, на которой все работает? Ядро работает, а сделать все равно ничего нельзя.

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

Микроядра - прошлый век. Даже экзоядра и гипервизоры - прошлое десятилетие.

А что нынешнее десятилетие?

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

Разве модуль не в одном адресном пространстве со всем остальным? Что мешает модулю испортить память других модулей?

Здравствуйте!

Расскажите пожалуйста про подвалы SpaceX.

Что мне за радость в том, что надежное микроядро не упало, когда упал и не может подняться драйвер файловой системы, на которой все работает? Ядро работает, а сделать все равно ничего нельзя.

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

Например, ядро может сообщить о падении драйвера FS приложениям. Допустим, это не локальная файловая система, а монтирование удалённой и её драйвер упал, тогда приложения могут сохранить какие-либо данные в локальный кеш.

Другой пример. Произошло падение драйвера GPU, можно его перезапустить и сообщить приложениям, что, допустим, OpenGL контекст надо переинициализировать. У меня несколько раз случалось падение драйвера AMD, при этом нормально ничего не сделать, только reboot.

Разделить ядро на части и реализовать обмен инфой между частями по некоторому протоколу.

Так при этом они останутся в одном адресном пространстве? Что помешает некоторому модулю напутать с указателями и перепахать всю память?

Что мне за радость в том, что надежное микроядро не упало, когда упал и не может подняться драйвер файловой системы, на которой все работает? Ядро работает, а сделать все равно ничего нельзя.

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

Но зато Darwin имеет все преимущества микроядра.

Гибридное и микро попутать

Там же гиДридное

Но зато Darwin имеет все преимущества микроядра.

Какие, если это не микроядро? Я правда не в курсе его устройства, но интересно.

Например, ядро может сообщить о падении драйвера FS приложениям. Допустим, это не локальная файловая система, а монтирование удалённой и её драйвер упал, тогда приложения могут сохранить какие-либо данные в локальный кеш.

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

Другой пример. Произошло падение драйвера GPU, можно его перезапустить и сообщить приложениям, что, допустим, OpenGL контекст надо переинициализировать. У меня несколько раз случалось падение драйвера AMD, при этом нормально ничего не сделать, только reboot.

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

Так при этом они останутся в одном адресном пространстве? Что помешает некоторому модулю напутать с указателями и перепахать всю память?

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

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

Это потому, что твоё ПО, хоть и работает под RT OS, не использует рекомендации для написания надёжного кода.

Это кто сказал, что моё ПО работает под RT OS? Изначально так вопрос не ставился. RT OS - это вообще отдельная песня. Это почему то топикстартер решил, что атомными станциями и космическими кораблями управляют «обычные» ОС с монолитным ядром. И, судя по всему, в его понимании замена этих ОС на такие же «обычные», но микроядерные сразу решит все проблемы.

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

Ну пусть так. У «железобетонно» надежной микроядерной ОС упал драйвер, управляющий приводом замедляющих стержней ядерного реактора, или кайо-нибудь заслонкой подачи топлива в реактивный двигатель. Микроядро живо, реактор/двигатель идут в разнос.

За критическими модулями, которые взаимодействуют с железом микроядерных ОС, следит отдельный сервер, так называемый, с повышенным приоритетом исполнения.

За критическими модулями, которые взаимодействуют с железом микроядерных ОС, следит отдельный сервер, так называемый, с повышенным приоритетом исполнения.

А за сервером с повышенным приоритетом исполнения следит сервер с еще более повышенным приоритетом исполнения? :-)

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

При разработке ПО мы вынуждены проектировать API. Что бы API был удобным он должен быть простым. Что бы API был удобным он должен быть функциональным. Но API не может быть и функциональным и простым. Да мы можем навернуть еще одни слой абстракции, разбить один API на несколько. Но сложность всей системы от этого не уменьшиться. Вот мы и живем с модульным ядром в линуксе, так как это оптимальный вариант.

1. Есть процессоры, которые десятки лет затачивались под монолит.
2. Поскольку процессоры заточены под монолит, микроядра тормозят. afaik на каком-нибудь интеле ты не можешь тупо прыгнуть в соседний процесс, тебе сначала надо прыгнуть в нулевое кольцо и там пихать разное в cr3.
3. Поскольку микроядра тормозят, все используют монолит.
4. Раз все используют монолит, то армо-интели дальше затачивают процессоры под монолит.
5. goto 1

Были какие-то подвижки в этом контексте в RISC-V, но я в этом не копенгаген.

Я с вами полностью согласен!

годноту подкидывали или сильно бояню ?? свежачок-с по микроядрам с опеннет

Выпуск операционной системы Redox OS 0.5, написанной на языке Rust

После года разработки подготовлен выпуск операционной системы Redox 0.5, разработанной с использованием языка Rust и концепции микроядра. Наработки проекта распространяются под свободной лицензией MIT. Для тестирования в VirtualBox или QEMU предложены готовые загрузочные образы.

Пользовательское окружение в Redox построено на базе графической оболочки Orbital, работающей поверх Wayland. В качестве web-браузера применяется Netsurf. Операционная система использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях. Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.

кто заюзает заценит - штампик «рвет пингвина как тузик грелку» поставит ??

Да хоть экзоядро!Какая разница, на каком ядре крутится ОС, если драйвера полукривые? Если прикладной софт жрёт и не захлёбывается, и хорошо, если в нём хоть память не течёт. А следующая версия жрёт ещё больше! При этом не особо прибавляя в функционале.
Железо только набирает мощность, потому никто не хочет как 90-е бороться за каждый такт процессора и за каждый килобайт памяти.
Зачем, если продукт уже сегодня можно продавать и получать прибыль? А завтра выпустят видяху, которая потащит эту игрушку на максималках! Ещё потребителя апгрейдить железо чаще заставляют! Все в плюсе!

Вполне мог бы миникс быть на их месте.

Открою страшную тайну, он уже есть и его очень-очень много на современном железе, т.к. он в Intel ME крутится на всех компах с интеловскими процессорами.

В хорошей системе Вася Пупкин вообще не ставит ключ никак. Нет того человека который мог бы его разболтать на Земле.

Это не интересно, там его не пощупать. Ну и это один из примеров.