Потому что начинать нужно с того, а кому это интересно на практическом уровне, а не на теоретическом)

VaStaNi, знаете ... Читаю Вашу переписку и наталкиваюсь на мысль каждый раз, что вы кричите, пытаетесь кому-то доказать. Читаю слова SII или Mario и вижу, что все, что им нужно выделить - они выделят, за счет речевых оборотов или на худой конец, выделением жирным. Про Ваш стиль речи есть хорошее высказывание (не помню чье): "Не кричи - внимательно слушают только то, что говорят шепотом". Поэтому рекомендация, если хотите серьезности восприятия Ваших слов: не надо набирать АРШИННЫМИ буквами и прочим выделять. И конечно, старайтесь связывать все Ваши тезисы грамотно.

Для меня аршинными и акцентировать или выделить одно и тоже с той лишь разницей, что не нужно мышью подчеркивать, ну типа лень. Если читается как кричишь, ну лаНо, бум вообще минимизировать, тем более скока раз боролся с этим.
Мне важно не услышанье, вообще, как правило, а понимание выделенного в первую очередь, т.к. это база, допустим для следующего. ок!

VaStaNi wrote:

SII wrote:Архитектура: монолитно-модульное ядро, но драйверы могут реализовываться как в виде модулей ядра, так и в виде задач прикладного уровня

с первой частью почти соласен, но требуется уточнение по поводу модульности. Нужен разворот понятия, видения. Что понимается, микрояденость и IPC или это "отдыхает", т.к.....

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

Вторая часть НЕ МОГУ приемлить. Драйвер для меня попадает почти в "уровень святости ядра" или лучше сказать его "обвязка", НО НИКАК НЕ ПРИЛОЖЕНИЕ!!!

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

SII wrote:а вот низкоуровневый драйвер, непосредственно обслуживающий устройство, -- в виде модуля ядра).

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

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

Сама загрузка ОС возможна двумя способами: "врассыпную" или "монолитом". Загрузка "врассыпную" предполагает, что загрузчик и программа инициализации ядра анализируют конфигурацию аппаратуры и грузят в память отдельно собственно ядро, отдельно модули HAL, отдельно каждый драйвер, ну а затем обеспечивают загрузку ещё и необходимых задач режима пользователя. Такой способ загрузки медленный, однако позволяет системе стартовать на любой аппаратной платформе, удовлетворяющей неким минимальным требованиям.

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

SII wrote:Средства реализации: ассемблер для модулей ядра, ассемблер или надёжный язык (на практике -- Паскаль

ЁЁЁ-маЁ! Ну в точку попал...

SII wrote:Категорически не приемлю Си/Си++

Ну по полной ты мне родня!

SII wrote:а при неумеренном использовании возможностей сваливать всю в одну кучу -- даже уменьшает

++++++++! За холивар не принимать! Просто родственники встретились

Весьма рад

SII wrote:Требования к системе: обязательная поддержка 64-разрядных процессоров, многопроцессорности, PnP, ACPI, в близкой перспективе -- UEFI...

НУ так ЗаКолбась сие! Или УЖЕ есть, что привнести?

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

SII wrote:В то же время считаю, что система должна строиться так, чтобы она могла работать и в качестве ОСРВ

+++1000000!!! Ну ты прям братан! Однозначно, воплощение в ядре ОСРВ технологий в плане хотябы "неубиенности ядра и базовых механизмов", базируясь на.... будет супрплюсом. При УМЕЛОМ проектировании ядра именно в этом плане, к чему и стремлюсь, десктопы ТОЛЬКО ВЫИГРАЮТ! А многие юзеры и даже кодеры(!) не почувствуют минусов, вернее наоборот - ПОЛУЧАТ НЕУБИЕННУЮ СИСТЕМУ. Вот я к чему

Ну, неубиваемость системы -- черта не только ОСРВ; в идеале такой должна быть любая система

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

НУ тут еще много о чем можно, хотя именно тут может и не стоит, а то споры затмят ветку

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

Плюс... гм-гм-гм... юзанье 4 уровневой защиты проца в системе. Тока не надо в меня помидорами сразу. Цель- живучесть, неубиенность, ТОТАЛЬНЫЙ КОНТРОЛЬ ЯДРОМ ВСЕХ и ВСЯ, вирусы не имеют никаких шансов, если бегло расклад такой...

Вирусы и так не будут иметь никаких шансов, если система нормальная, а пользователь -- не полный лох (а если у всех подряд права админа, то проблем не избежать). Лично я против использования 4-уровневой защиты: усложение реализации, её замедление (прыжки через кольца выполняются медленнее, чем на одном уровне), отсутствие аналогичного механизма в большинстве процессоров (конечно, систему "в лоб" не перенесёшь с IA-32 на ARM, особенно если она на асме написана, однако даже подробный технический проект будет почти полностью переносимым, а именно проектирование -- самое сложное, нудное и т.п. в создании осей). Да и не вижу, если честно, практической пользы от такого разделения: зловредное поведение (предумышленное или нет, роли не играет) непривилегированного кода во вменяемой системе опасно максимум для владельца этого кода (т.е. он сможет нагадить только там, где этот владелец имеет соответствующие права), ну а такое же поведение "общесистемного" кода (драйвера, например) всё равно приведёт к очень серьёзным пролемам для всех, и никакой изоляцией на уровне привилегий процессора здесь не обойтись. ИМХО, вполне достаточно двух уровней (0 и 3) и возможности выноса на уровень задач тех драйверов, которые в ядре не очень-то нужны или по каким-то причинам нежелательны (например, ещё не отлажены и постоянно глючат).

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

VaStaNi wrote:Для меня аршинными и акцентировать или выделить одно и тоже с той лишь разницей, что не нужно мышью подчеркивать, ну типа лень. Если читается как кричишь, ну лаНо, бум вообще минимизировать, тем более скока раз боролся с этим.
Мне важно не услышанье, вообще, как правило, а понимание выделенного в первую очередь, т.к. это база, допустим для следующего. ок!

Раз уж об этом речь... Я бы попросил повнимательней относиться к изложению мыслей, разделению на предложения, пунктуацию и прочее: читать попросту тяжело, а понимать -- ещё тяжелее. Я понимаю, что не все являются академиками по русскому языку, но хотя б сами фразы более чётко и понятно строить, без излишних сложностей, и не валить всё подряд в один абзац. Ну и БОЛЬШИЕ БУКВЫ постоянно тоже раздражают, если честно. Я, когда лень, использую примерно _такое выделение_, но это уже как кому нравится.

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

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

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

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

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