Re: Предварительные наброски по проектированию микроядра
Posted: Wed Sep 29, 2010 11:45 am
(с) бред - удалено автором
Именно монолитное ядро, поскольку собственно ядро и "ядерные" драйверы работают в общем адресном пространстве, т.е. никак не защищены от вмешательства друг друга. Взаимодействие -- через чётко определённые и расписанные интерфейсы на основе вызова подпрограмм, т.е. как в классических монолитах. Обоснование простое: это проще в реализации и быстрей работает.VaStaNi wrote:с первой частью почти соласен, но требуется уточнение по поводу модульности. Нужен разворот понятия, видения. Что понимается, микрояденость и IPC или это "отдыхает", т.к.....SII wrote:Архитектура: монолитно-модульное ядро, но драйверы могут реализовываться как в виде модулей ядра, так и в виде задач прикладного уровня
При желании его можно переименовать Например, в древней (и моей любимой) RSX-11 вводом-выводом "заведовали" три категории кода: менеджер ввода-вывода (часть ядра системы), драйверы устройств (тоже физически часть ядра, хотя логически это отдельные модули, которые могли быть загружены-выгружены независимо от остальной системы) и вспомогательные управляющие процессоры (ACP), которые по сути и были драйверами пользовательского режима, оформленными в виде привилегированных задач. ACP применялись в первую очередь для реализации файловых систем (хотя теоретически можно было сделать и полноценный драйвер, работающий с железом), а вот драйверы непосредственно обслуживали аппаратуру. Запросы на файловый ввод-вывод через менеджер ввода-вывода (он же является единой точкой входа для всех запросов ввода-вывода) передавались соответствующему ACP, а тот уже выдавал необходимые низкоуровневые запросы (типа "считать блок № такой-то"). Возможность подобного разделения кажется мне удобной и полезной: во-первых, код пользовательского режима проще писать и отлаживать, а во-вторых, там не столь важна скорость его исполнения, да и сам он подвергается воздействию планировщика, как любая другая задача, а значит, не сможет тормозить высокоприоритетные вещи. В то же время, если окажется, что задача-драйвер вносит слишком большие накладные расходы, её всегда можно переделать в драйвер режима ядра, что в микроядерной системе невозможно в принципе.Вторая часть НЕ МОГУ приемлить. Драйвер для меня попадает почти в "уровень святости ядра" или лучше сказать его "обвязка", НО НИКАК НЕ ПРИЛОЖЕНИЕ!!!
Ну, если не углубляться в детали, моя мысля такая... Само по себе "голое" ядро не умеет работать с железом (кроме самого процессора, естественно) -- оно реализует лишь функции, которые в принципе не зависят от конфигурации аппаратной части: планировщик, менеджер памяти, менеджер ввода-вывода (который принимает и "разруливает" запросы по драйверам, но сам выполняет лишь определённую их часть, не зависящую от устройств -- например, умеет отменять запросы ввода-вывода, которые уже были поставлены в очередь, но ещё не запущены на выполнение) и т.д. С железяками же работают почти исключительно драйверы; исключением являются, например, таймеры, контроллеры прерываний, ACPI: логически их обслуживанием занимается собственно ядро, физически -- отдельные модули, загружаемые вместе с ядром (можно считать, что это HAL такой), благодаря чему одно и то же ядро может быть запущено, например, на машине с APIC и с просто PIC: просто грузятся разные модули.поддерживаю. С уточнением. Т.е. есть инкапсулированный в ядро модуль драйверов или согласно моей терминологии драйвера де-факто, т.е. те драйвера, без которых ядро или "без рук и ног и глаз" или по сути мертво (уход от недостатков или проблемы микроядерности) ничего САМО не может. Должна быть начальная живучесть (концепт). Поясню шире тут, раз пошла такая "жара"...SII wrote:а вот низкоуровневый драйвер, непосредственно обслуживающий устройство, -- в виде модуля ядра).
Весьма радЁЁЁ-маЁ! Ну в точку попал...SII wrote:Средства реализации: ассемблер для модулей ядра, ассемблер или надёжный язык (на практике -- ПаскальНу по полной ты мне родня!SII wrote:Категорически не приемлю Си/Си++++++++++! За холивар не принимать! Просто родственники встретилисьSII wrote:а при неумеренном использовании возможностей сваливать всю в одну кучу -- даже уменьшает
Я уже писал: сначала -- полноценный проект. Писать что-либо "по наитию" не собираюсь: ничего путного в конечном итоге не выйдет; ось -- слишком сложная штука, чтобы создавать её хаотически. В настоящее время для себя почитываю спеку ACPI, когда дочитаю (через месяц примерно), сделаю утилитку для разбора всех таблиц и прочего и вывода в файл: потом будет полезно при отладке (можно посмотреть, что ACPI сообщает системе), да и сам на практике, а не только в теории, с частью вещей разберусь. После этого можно и с UEFI поковыряться, благо, интеловская плата с его поддержкой имеется; но это больше для того, чтобы понять: а не потребуется ли внесение каких-то изменений собственно в систему, а не только в программу её загрузки и инициализации.НУ так ЗаКолбась сие! Или УЖЕ есть, что привнести?SII wrote:Требования к системе: обязательная поддержка 64-разрядных процессоров, многопроцессорности, PnP, ACPI, в близкой перспективе -- UEFI...
Ну, неубиваемость системы -- черта не только ОСРВ; в идеале такой должна быть любая система+++1000000!!! Ну ты прям братан! Однозначно, воплощение в ядре ОСРВ технологий в плане хотябы "неубиенности ядра и базовых механизмов", базируясь на.... будет супрплюсом. При УМЕЛОМ проектировании ядра именно в этом плане, к чему и стремлюсь, десктопы ТОЛЬКО ВЫИГРАЮТ! А многие юзеры и даже кодеры(!) не почувствуют минусов, вернее наоборот - ПОЛУЧАТ НЕУБИЕННУЮ СИСТЕМУ. Вот я к чемуSII wrote:В то же время считаю, что система должна строиться так, чтобы она могла работать и в качестве ОСРВ
Ну, потому и не хочу особо что-то обсуждать здесь -- только краткое изложение мыслей без особых дискуссий и т.п.НУ тут еще много о чем можно, хотя именно тут может и не стоит, а то споры затмят веткуSII wrote:в первом приближении это сводится к тому, что время её реакции на прерывания должно быть предсказуемым: для любого заранее известного набора оборудования должна иметься возможность точно посчитать наихудшее возможное время от поступления запроса на прерывание от конкретного устройства до начала выполнения первой команды обработчика этого прерывания
Вирусы и так не будут иметь никаких шансов, если система нормальная, а пользователь -- не полный лох (а если у всех подряд права админа, то проблем не избежать). Лично я против использования 4-уровневой защиты: усложение реализации, её замедление (прыжки через кольца выполняются медленнее, чем на одном уровне), отсутствие аналогичного механизма в большинстве процессоров (конечно, систему "в лоб" не перенесёшь с IA-32 на ARM, особенно если она на асме написана, однако даже подробный технический проект будет почти полностью переносимым, а именно проектирование -- самое сложное, нудное и т.п. в создании осей). Да и не вижу, если честно, практической пользы от такого разделения: зловредное поведение (предумышленное или нет, роли не играет) непривилегированного кода во вменяемой системе опасно максимум для владельца этого кода (т.е. он сможет нагадить только там, где этот владелец имеет соответствующие права), ну а такое же поведение "общесистемного" кода (драйвера, например) всё равно приведёт к очень серьёзным пролемам для всех, и никакой изоляцией на уровне привилегий процессора здесь не обойтись. ИМХО, вполне достаточно двух уровней (0 и 3) и возможности выноса на уровень задач тех драйверов, которые в ядре не очень-то нужны или по каким-то причинам нежелательны (например, ещё не отлажены и постоянно глючат).Плюс... гм-гм-гм... юзанье 4 уровневой защиты проца в системе. Тока не надо в меня помидорами сразу. Цель- живучесть, неубиенность, ТОТАЛЬНЫЙ КОНТРОЛЬ ЯДРОМ ВСЕХ и ВСЯ, вирусы не имеют никаких шансов, если бегло расклад такой...
Раз уж об этом речь... Я бы попросил повнимательней относиться к изложению мыслей, разделению на предложения, пунктуацию и прочее: читать попросту тяжело, а понимать -- ещё тяжелее. Я понимаю, что не все являются академиками по русскому языку, но хотя б сами фразы более чётко и понятно строить, без излишних сложностей, и не валить всё подряд в один абзац. Ну и БОЛЬШИЕ БУКВЫ постоянно тоже раздражают, если честно. Я, когда лень, использую примерно _такое выделение_, но это уже как кому нравится.VaStaNi wrote:Для меня аршинными и акцентировать или выделить одно и тоже с той лишь разницей, что не нужно мышью подчеркивать, ну типа лень. Если читается как кричишь, ну лаНо, бум вообще минимизировать, тем более скока раз боролся с этим.
Мне важно не услышанье, вообще, как правило, а понимание выделенного в первую очередь, т.к. это база, допустим для следующего. ок!
Не забудь указать и мою позицию где-нибудь в уголке:maximYCH wrote:Никто не против, если я тезисно запишу мнения всех, постаравшись не переврать? А то написано много и по-всему форуму писалось ...
Именно это и надо рассматривать, обсуждать и т.д. А споры "микроядро или монолит" на начальном этапе попросту бессмысленны: какая разница, что это такое, если непонятно, на чём оно будет работать и что конкретно делать (ОС создаётся ж не ради самой себя, а для выполнения под ней прикладных программ).1. Очерчивается круг задач, для которых будет предназначена система -- как ближайший, так и в достаточно отдалённой перспективе.
2. Очерчивается аппаратная база, для которой она предназначается.
3. Определяется, какие системные сервисы предоставляются прикладному программисту. Например, могут ли две задачи совместно пользоваться одной и той же областью памяти? Частный случай предыдущего: могут ли они совместно использовать одну и ту же копию динамически загружаемой библиотеки? Как выдаются права на доступ и как (с точки зрения прикладника, подчёркиваю это) они контролируются? Каким образом между задачами поддерживаются отношения "родитель-потомок"? Каким образом задачи выполняют операции ввода-вывода? Ну и т.д. и т.п.