Возвращение микроядра

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

Если вся надежда на изменение архитектуры, то почему бы вам не вспомнить про судьбу итаниума ? Интел тоже ведь хотел избавиться от архитектуры х86 при помощи итаниума.

А в результате имеем архитектуру амд64, кан наследницу и эволлюционное развитие х86 и существенное сокращение доли Интела на процессорном рынке. Ситуация возращается к началу - середине 199х годов.

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

Выводы делайте сами

>Когда не знаете, или не понимаете о чем речь, лучше смолчать. Вирт рассказывал о своем последнем языке, оберон-2,

Пролистал http://www.uni-vologda.ac.ru/oberon/o2rus.htm

И чем это круче всех остальных?

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

существует еще 1 вариант - значительное увеличение кол-ва софта под линукс, в результате чего исчезнет зависимость от конкретного процессора

это тоже вариант, согласен

>Широкое распространение и бурный рост рынка распределенных вычислений, в том числе, в связи с real-time обработкой звука и видео.

Вот тут хотелось бы подробнее. Чем более медленное микроядро может помочь с обработкой звука и видео в реальном времени.

>3. Дальнейший рост производительности аппаратного обеспечения.

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

В распределенные вычисления соваться не буду.

А чем в кофемолке микроядро лучше монолита?

> А чем в кофемолке микроядро лучше монолита?

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

Вот еще 108 комментариев (правда не на русском) на данный момент в тему "Torvalds Comments on Micro vs. Monolithic Debate"

http://www.osnews.com/comment.php?news_id=14571

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

Вот до этого места - совершеннно верно.

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

ЗАБЛУЖДЕНИЕ. На самом деле всё с точностью до наоборот.

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

Как показывает практика, достаточно просто разнести ядро, драйвера и приложения в разные адресные пространства и не использовать разделение на кольца защиты.

>Это только в singularity редактор будет иметь доступ ко всему адресному пространству.

В singularity редактор будет иметь доступ только к своим объектам и надежным объектам ядра. Доступность объектов контролируется при компиляции перед запуском программы. Уберите из C++ адресную арифметику, встроенный ассемблер, добавьте проверку границ массивов и попробуйте перезаписать любой объект в своем же адресном прострастве.

>А драйвер, некорреткно инициализирующий dma будет в обоих системах, причем для инициализации dma требуется привилегии нулевого кольца: как вы это собираетесь делать в userspace драйвере?

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

> Сравнивать инструкцию call с массой телодвижений с постановкой/отправкой/принятием сообщения в/их очереди этих сообщений..... ну... тяжко как минимум :)

В этом вопросе Вы отстаёте как миниму на пять лет. Какие, нафиг, очереди? Вы о синхронных IPC слышали?

> НЕВОЗМОЖНО не потерять производительность на микроядре. Даже простое переключение контекста (а каждое дровижко там в отдельном процессе!) это УЖЕ далеко не просто call/ret...

ВОЗМОЖНО! Для этого были придуманы LIPC. Т.е. local IPC. Вырождаются в те же самые call/ret

> Хотя, даже не эти несколько сотен инструкций на передачу управления в другой модуль проблема. Счас железо вприницпе, на уровне. Проблема в офигенной сложности этого всего. И то, что УЖЕ наработанное в линухе будет практически невозможно перенести на архитектуру микроядра (это просто никто не захочет делать. Были бы желающие - уже были бы проекты)

Это исключительно проблема дизайна ядра. Точнее его отусутствия. Менее чем через десяток лет ядро Линукса станет невозможно поддерживать из за его сложности.

>Как показывает практика, достаточно просто разнести ядро, драйвера и приложения в разные адресные пространства и не использовать разделение на кольца защиты.

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

> В микроядре (кстати, minix умеет работать с сетью?), по законам жанра, сетевой драйвер будет в отдельном потоке на отдельном кольце, т.о. мы получим 2 системных вызова (userspace->protocol handler, protocol hanler -> NIC irq).

> В микроядре _КАЖДОЕ_ обращение между различными подсистемами будет занимать столько времени.

Весьма и весьма неудачный пример. Даже если не брать во внимание local IPC. Забудьте о кольцах защиты. Забудьте об userspace и kernelspace. Это старые догмы. При такой реализации действительно сеть будет тормозить - т.е. Вы переносите идеологию монолитного ядра в реализацию системы на микроядре.

Хотите правмльный путь? Представьте сетевую карту как стрим Ethernet фреймов, который ничего не знает о других протоколах, модулях и о ядре. Его задача - передать посредством IPC принятые фреймы другому фильтру, например, парсеру IP пакетов. Парсер IP пакетов раздаёт пакеты TCP и UDP фильтрам. И так далее по всему стеку протоколов. Полная абстракция - связи между фильтрами протолов осуществляются исключительно посредством чётко документированных интерфейсов. Более того, Вы имеете возможность вставить свой собственный фильтр между протоколами не затрагивая их реализации.

Если Вы утверждаете что это будет тормозить, то посмотрите ещё раз в исходники ядра Линукса.

>Менее чем через десяток лет ядро Линукса станет невозможно поддерживать из за его сложности.

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

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

Мне до последнего момента не хотелось переходить на личности, однако Ваша категоричность... Не надо мыслить категориями прошлого века - посмотрите в сторону L4. Грамотно реализованные IPC позволяют легко избавиться, например, от spinlocks на многоядерных и многопроцессорных системах.

>> А Вы не просветите нас сколько колец у Athlon'a в 64-х битном режиме?

> Но нужно больше :) Чтобы микроядро работало хорошо, и прогнозы сбывались.

Зачем нужны кольца? Вы не находите, что в любой многозадачной системе каждый процесс существует в своём адресном пространстве? Процесс не может обратиться к памяти или устройству ввода/вывода, которые не отображены в его адресное пространство. Механизм уровней защиты по кольцам привелегий был необходим для Intel 80286, который не поддерживал виртуальных страниц.

Процессы, участвующие в IPC не могут обойтись без третьей стороны. Должны соблюдаться права доступа и это может обеспечить только независимая сущность. Если на существующем железе скопировать в общую область памяти еще можно без участия ядра (если повезет обойтись без page-fault), то передавать управление или разбудить чужой процесс нужно только с помощью ядра. Только привелегированная сущность должна иметь право "отбирать" процессор и возобновлять исполнение с _нужной_ точки, а не в произвольном месте. Сейчас без переключений контекстов никак нельзя. Singularity/Оберон переносят проверки на время компиляции и IPC там возможно без участия ядра и MMU

>Зачем нужны кольца? Вы не находите, что в любой многозадачной системе каждый процесс существует в своём адресном пространстве? Процесс не может обратиться к памяти или устройству ввода/вывода, которые не отображены в его адресное пространство. Механизм уровней защиты по кольцам привелегий был необходим для Intel 80286, который не поддерживал виртуальных страниц.

Хорошо, пусть останутся только таблицы страниц без колец. Кто будет настраивать отображения, к кому обратится процессор в случае чего? Непривелигированный процесс? Тогда любой другой процесс сможет захватить процессор, ведь у всех одинаковые права. Просто тупо перепишет содержимое CR регистров. Ядро нужно, пусть даже микро. И у него должны быть исключительные полномочия. Даже в singularity загрузчик должен создавать объекты, а значит иметь доступ к памяти, без ограничений.

> Вряд ли. Хоть вы и вырываете мои мысли из контекста, смысл остается тем же самым: только новые идеи и мысли могут потеснить привычный уклад, поэтому микроядерность, как чрезвычайно неэффективный подход, ничего сделать не сможет.

Источником слухов о неэффективности микроядерности являются: 1. Линус Торвальдс 2. Микроядро Mach

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

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

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

Я показал Вам что Вы заблуждаетесь. Повторяю:

1. Local IPC (в пределах одного адресного просстранства) 2. Synchronous IPC (не нужны дополнительные буфера и копирование) 3. Другая концепция в реализации межпроцессорного взаимодействия. (уход от семафоров и критических секций, использование конечных автоматов) Боюсь, третий пункт вызовет у Вас приступ смеха. Казалось бы, причем тут конечные автоматы? Я попытаюсь объяснить, но боюсь у меня не хватит преподавательских способностей. Да и без бумаги с карандашом я этого объяснить не смогу. Смысл в том, что запросы от протоколов верхнего уровня и ответы от протоколов нижнего уровня имеют одну точку входа. Без конечных автоматов аналогичного результата можно добиться путём динамического переключения стеков на каждый запрос от верхнеуровнего протокола.

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

> Возможно, вы хотите компенсировать производительность безопасностью,

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

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

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

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

Это очень хорошо, что я поздно подключился к обсуждению. Лишний раз "пинаю" Вас за то, что Вы путаете кольца защиты и адресные пространства.

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

Поэтому как бы мы не определяли, микро-ядерная ОС состоит из нескольких компонентов работающих одновременно. Если они рботают одновременно, то они(компоненты) обязательно должны обмениваться данными. Всякий обмен данными обязательно будет потреблять ресурс в той или иной форме. Подчеркиваю, я специально ничего не говарю о щелканье контекстом и межпроцесном взаимодействии. Реализация транпорта данных преднамеренно выведена за рамки рассмотрения.

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

На лицо неустранимый коцептуальный дефект микроядерной ахитектуры.

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

С чего же тогда весь этот базар. Дело в том, что разработка микроядра проще и лудше управляется. Я, и многие из вас, прочтя всем извеную книгу поймут, что существует некий алгорифм написания микроядра. Поднатужившись я напишу нечто над чем, быть может, все будут смеятся и показывать пальцем, но это будет работать. "Hello World" напишет точно и пусть очень медленная но полноценная ОС получется. А вот монолит написать у меня точно пупок развяжется. Поэтому мироядерных независимых осей много. А монолиты можно перечесть по пальцам. В пользу серьезности дефекта говорит то, что монолиты все эксплуатируются а микроядра объекты музея.

Монолит писать могут только немногие. И это просто чудо или дар что Линус выстрогал свой Линукс иначе небыло бы никакого свободного софта. Такие вещи надо уметь ценить и нераспылятся на микроядерные пусть часто приятные заблуждения

> Они медленные. Выше даже цифры приведены для времени выполнения пустого syscall.

Вызывающе неверная информация. Они, это кто? Mach? Посмотрите в сторону L4.

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

Вызывающе неверная информация. Подавляющее число ошибок возникают по вине программиста. Что значит незавершённый драйвер? Недописанный или не ответивший на запрос?

> Они сложны. Механизм межпроцессорного взаимодействия всегда сложение например вызова функции (call/ret).

Вызывающе неверная информация. Они красивы и интуитивно понятны. Интерфейсы отделены от реализации. Как Вы будете масштабировать на многопроцессорной системе при помощи call/ret?

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

Вызывающе неверная информация. Как раз таки механихм IPC позволяет легко масштабироваться на любое число процессоров.

А насчёт взаимных блокировок - ПРИМЕР В СТУДИЮ.

> Чудак ты о0днако. Ему приходили немало предложений модернизировать minix(не пустые, а посылки патчей), однако он отказывался. Задача minix'a состояла в том, чтобы студенты поняли устройство ОС. Не больше...

Во во. Один япошка шутя портанул Миникс поверх Hazelnut. Причём, изменения в Миниксе были незначительные.

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

В теории, мой друг, в теории. Где на практике используется эта возможность? Покажите пример кода.

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

> Монолит писать могут только немногие. И это просто чудо или дар что Линус выстрогал свой Линукс иначе небыло бы никакого свободного софта. Такие вещи надо уметь ценить и нераспылятся на микроядерные пусть часто приятные заблуждения

Просто Линус был первый, кто выложил своё ядро во всеобщий доступ. Насколько я осведомлён, в то время у Миникса была не очень открытая лицензия.

> Хорошо, пусть останутся только таблицы страниц без колец. Кто будет настраивать отображения, к кому обратится процессор в случае чего? Непривелигированный процесс? Тогда любой другой процесс сможет захватить процессор, ведь у всех одинаковые права. Просто тупо перепишет содержимое CR регистров. Ядро нужно, пусть даже микро. И у него должны быть исключительные полномочия. Даже в singularity загрузчик должен создавать объекты, а значит иметь доступ к памяти, без ограничений.

Я не знаком с singularity, но могу рассказать как это организовано в L4. Изначально вся память принадлежить процессу sigma0. Он поддерживает два протокола - один, выделения памяти ядру, другой, для выделения памяти остальным процессам. Каждый процесс имеет pager, который принимает исключения по обращениям к неотображённым страницам. При возникновении такого исключения, pager принимает решение - отобразить страницу в адресное пространство процесса или игнорировать или даже уничтожить процесс. Анализ может быть произведён, например, на основе сегментов CODE, DATA, BSS, STACK, которые могут быть получены из Elf заголовка. Естественно, для того чтобы pager мог отобразить страницу в адресное пространство процесса, эта страница должна быть отобрадена в адресное пространство pager'а. Если страница не отображена в адресное пространство pager'a то он может запросить её у sigma0, или обратиться к ней, что, в свою очередь, вызовет аналогичное исключение у родительского pager'а.

>а че так все критикуют? по моему,
>мысль правильная - только вот кто ее реализует?

>Toxa (*) (08.05.2006 22:07:13)

MAC OSX, на микроядре, ставится на обычные писюки:

http://forum.ru-board.com/topic.cgi?forum=35&topic=29990&start=940#12

К гуёвому интерфейсу надо конкретно привыкать и приспосабливаться.
Удивила скорость загрузки - 20-25 сек.
Визуально все работает шустро, но вот кто-то натестил, что линух
шустрее в три раза(сомневаюсь):
http://sekhon.berkeley.edu/macosx/intel.html

Форк БСД - DragonFly, там вроде пытались как то по другому организовать работу с потоками и процессами. Может имело бы смысл поинтересоваться как обстоит дела у них ?

>Только не будет этого НИКОГДА. Мы навечно застряли в x86... застряли, скажите спасибо виндузятникам и пр. любителям закрытого софта.

>Вот тут хотелось бы подробнее. Чем более медленное микроядро может помочь с обработкой звука и видео в реальном времени.

Тем что микроядро легче заставить работать в условиях жесткого реального времени

>В теории, мой друг, в теории. Где на практике используется эта возможность? Покажите пример кода.

Теория и практика это не два врага стремящихся уничтожить друг друга. Между ними существует реальная связь. Кто этой связи не ловит посей день собирает вечные двигатели и при каждой неудаче говорит "Вот блин! Еще немного и получилось бы!". Практика беспощадней к микроядрам чем теория. монолиты доминируют. Сслками на теорию можно обосновать бесперспективность развития микроядер.

>И эта теория со свистом летит для многопроцессорных приложений. Как только появляктся возможность обращения к какому либо ресурсу несколькими процессами, тут же приходится извращаться с синхронизацией.

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

>Просто Линус был первый, кто выложил своё ядро во всеобщий доступ. Насколько я осведомлён, в то время у Миникса была не очень открытая лицензия.

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