Новая ветка ядра

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

    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:Категорически не приемлю Си/Си++
    Ну по полной ты мне родня! :lol: :lol: :lol:
    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. При удачной реализации можно будет легко строить гибриды, т.е. системы, в которых успешно сосуществуют модули ядра и серверные процессы режима пользователя (прикладного уровня).
  • Ну, внутри ядра клиент-серверная модель не нужна: эффективность ниже, чем у обычных вызовов подпрограмм (хотя тут границы довольно расплывчаты: например, запросы ввода-вывода менеджером ввода-вывода выстраиваются в очереди к соответствующим драйверам, а драйверы выбирают их оттуда по мере возможности, т.е. это своего рода обработка входящих сообщений специализированного формата). Ну а для задач, естественно, должны быть механизмы API, позволяющие реализовать клиент-серверное взаимодействие.
  • maximYCH wrote:Никто не против, если я тезисно запишу мнения всех, постаравшись не переврать? А то написано много и по-всему форуму писалось ...
    Не забудь указать и мою позицию где-нибудь в уголке:

    1) 100% монолит (безмодульный и в идеале - бездрайверный) с элементами RTOS. Ассемблер. х86 на первом этапе, АМД64 - на втором.
    2) Нативная поддержка APIC с отдельными элементами ACPI. Поддержка PCIe, USB, SATA, включая хотплаг. ROM-загрузка.
    3) Код заточить под одну перспективную и открытую платформу с поддержкой нескольких родственных чипсетов ядром.
    (от универсальной поддержки всех платформ при таком подходе придется отказаться)
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Я думаю, что правильнее, когда каждый сам высказывает мнение по отдельному вопросу, описывает свое виденье так сказать. Определившись с решением одного вопроса, можно приступать к рассмотрению следующего. Начать нужно с наиболее общих вопросов типа архитектуры ядра, режимов работы, возможного (коммерческого) применения на начальном этапе становления системы и т.п. Тогда уже можно будет объединяться по интересам, а так это похоже на обсуждения, которые уже неоднократно велись и всем известно чем заканчивались. Не думаю, что ради этого все затевалось.
  • Процитирую самого себя:
    1. Очерчивается круг задач, для которых будет предназначена система -- как ближайший, так и в достаточно отдалённой перспективе.

    2. Очерчивается аппаратная база, для которой она предназначается.

    3. Определяется, какие системные сервисы предоставляются прикладному программисту. Например, могут ли две задачи совместно пользоваться одной и той же областью памяти? Частный случай предыдущего: могут ли они совместно использовать одну и ту же копию динамически загружаемой библиотеки? Как выдаются права на доступ и как (с точки зрения прикладника, подчёркиваю это) они контролируются? Каким образом между задачами поддерживаются отношения "родитель-потомок"? Каким образом задачи выполняют операции ввода-вывода? Ну и т.д. и т.п.
    Именно это и надо рассматривать, обсуждать и т.д. А споры "микроядро или монолит" на начальном этапе попросту бессмысленны: какая разница, что это такое, если непонятно, на чём оно будет работать и что конкретно делать (ОС создаётся ж не ради самой себя, а для выполнения под ней прикладных программ).
  • art_zh, что так жестко в плане архитектуры? Хочешь ядро куда-то впаять? Дело в том, что от модульности легко перейти к чистому монолиту, а вот обратно при необходимости, особенно если это делать в торопях, можно наклепать кучу костылей. К тому же, модульность дисциплинирует разработчика, не давая ему возможности плодить паразитные связи, от которых со временем будет масса проблем.

    SII, от архитектуры зависит, кто сможет и захочет участвовать в разработке ядра. Я к примеру только слежу за соседней веткой форума, но здесь уже пишу и готов высказывать свое мнение по реализации, т.к. заметил, что в последних постах здесь присутствующих четко прослеживается приверженность к архитектуре, которая мне симпатична и знакома не только в теории.
  • Разработка -- понятие растяжимое. Один и тот же API может быть реализован в системах разных архитектур. Для меня, например, именно функционал системы и её целевая направленность являются первичными (ещё первичнее только систематический подход к разработке: сначала проектирование, а потом уже реализация), а уж какая архитектура будет -- это вторично. Кроме того, ничто не мешает разным группам "по интересам" реализовывать один и тот же API разными способами: если кто-то категорически не приемлет микроядерность, пускай лепит монолит, и наоборот. Ну а участвовать в обсуждении возможностей системы и её API можно и вообще не собираясь принимать участия в дальнейшей реализации.
  • Who is online

    Users browsing this forum: No registered users and 2 guests