OSDev

Посмотрел, что написано про экзоядро на Вике, и очередной раз пришёл к выводу: бред.

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

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

А вот с экзоядром получается мистика. Цитирую оттуда:



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

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

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

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

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

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



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



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



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



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



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



Вот сначала придумайте, а потом говорите. Ну а заодно поизучайте другие архитектуры -- очень полезно. Конечно, архитектура ИА-32 -- жутко кривая, но абсолютно во всех архитектурах ввод-вывод связан либо с доступом к регистрам устройств, либо с выполнением специальных команд ввода-вывода, либо с тем и другим, ну а плюс -- с обработкой прерываний, а посему проблемы остаются те же самые: нередко невозможно обеспечить надёжную защиту драйверов друг от друга (т.е. сделать так, чтобы один драйвер никакими ухищрениями не мог нанести ущерб другому драйверу -- залезть в чужую память или там обратиться к чужому устройству), ну а в тех случаях, когда это технически осуществимо, это приводит к существенному падению производительности.



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



Британские учёные тоже много чего изучают -- но на практике почему-то используются в основном монолиты или же не совсем полноценные микроядра (вроде QNX).



Извините, но тут Вы сказали полный бред. Процессор и оперативная память работают без всякого ядра вообще; максимум, что им нужно, да и то не во всех архитектурах, -- это предварительная настройка кой-каких "железных" параметров, чем ядра систем не занимаются в принципе (в ПК все необходимые настройки процессора и чипсета выполняет BIOS).



Насчёт "знает" -- не знаю. Однако именно такой подход теоретически обеспечивает наивысшее качество кода под любую платформу. При классической компиляции исходный текст программы компилируется в машинный код один раз, поэтому он может быть наилучшим образом оптимизирован лишь под одну платформу. Например, если требуется, чтобы некая программа работала на любых 64-разрядных процессорах архитектуры ИА-32, она в принципе не может использовать инструкции SSE4 и более поздние (а возможно, и не все SSE3, тут уж не помню) -- а соответственно, она может оказаться не самой эффективной для более новых процессоров. В то же время динамический компилятор вроде Жабы способен компилировать именно под тот процессор, на котором код реально будет сейчас выполняться, а значит, сделать это эффективнее.

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



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



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

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

Ну, спешить-то некуда :) Так что ждём-с.

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

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

Подскажите, а на этом форуме можно создавать шапки в темах, потипа как на forum.ru-board.com ?
Хочу выложить информацию для всеобщего обозрения по обозначенной теме которая у меня имеется(книги, ссылки и пр.)

phantom-84


Добавлю: теоретически имеет, а на практике -- это уж насколько криво спроектировано и реализовано.



Аналогично. Точней, предпочитаю монолитно-модульную систему с возможностью выноса значительной части драйверов за пределы ядра (из современных систем таковыми являются Висла и Семёрка, таковой во время оно была и моя любимая RSX-11).

chizh


На самом-то деле бывают, и пресловутый ХеллоВорлд -- тому пример: в любых штатных условиях он отработает корректно и выполнит все свои функции :) Собственно, компактность отдельных логических модулей системы очень способствует уменьшению количества ошибок (драйвер в 500 строк с большей вероятностью будет безошибочным, чем в 50 000). На компактность напирают апологеты микро- и экзоядерных систем, однако не принимают во внимание тот факт, что, если некоторый модуль работает безошибочно, нет нужды изолировать его от других безошибочных модулей; соответственно, роль играет не минимальный размер ядра как такового, а размеры входящих в его состав модулей.

Groms


Понятия не имею. Наверное, нет...

Проблема в том, что не всегда известно что безошибочно, а что нет. Доведение до безошибочного состояния в случае с большими программами очень долгий и трудный процесс. Ваш драйвер не получиться использовать пока вы полностью не проверите. А в случае, когда он в пользовательском режиме баги можно исправлять уже потом и при этом пользователи много не потеряют. В случае с микроядром надо тщательно спроектировать и отладить лишь очень маленький код ядра, а код драйверов можно отлаживать уже потом. И самое главное - вы можете назвать свою ОС "самой стабильной на свете" ещё до того, как отладите драйвера. Вы не можете заставить всех писать исключительно безошибочные программы. Поэтому лучше ОС, которая будет работать относительно стабильно даже если на ней запускать кривые драйвера (а как бы мы не хотели обратного они будут всегда). К тому же в микроядре есть только функции независищие от процессора - на любой архитектуре нужен менеджер памяти, возможность ставить обработчики исключений и аппаратных прерываний, и управлять процессами и потоками. Таким образом можно разработать API, который будет одинаков на любой архитектуре - хоть на PC, хоть на сотовом телефоне. Драйвер режима ядра как правило нельзя перезагрузить, если он этого не умеет или умеет с ошибкой - останутся занятые ресурсы. В случае с приложением-драйвером при его завершении или перезапуске ресурсы освободятся вне зависимости от корректности драйвера.

KIV


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

- управление потоками;
- управление сигналами;
- обмен сообщениями;
- планирование потоков;
- управление таймерами;
- управление процессами.

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

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



А тут уже прямая Ваша ошибка. Все приведённые Вами примеры прямо зависят от архитектуры процессора, причём так сильно, что по крайней мере часть из них придётся писать на ассемблере (пускай этой частью будут даже отдельные инструкции, вставленные в код на ЯВУ). Так что такое микроядро зависит от процессора всегда :)