OSDev

Я не говорю, что микроядро не зависит от процессора. Я даже предложил, что его имеет смысл написать на чистом ассемблере (а уж такой код перенести нельзя даже с 32 бит на 64 одного и того же процессора). Я говорю, что набор API предоставляемый ядром будет одинаков на любой архитектуре, потому что во всех существующий архитектурах есть память и прерывания и поскольку ОС многозадачная, то будут процессы, потоки и механизмы IPC. А в вашем случае на каждой архитектуре будет дополнительный набор API. Например, на PC будет ACPI. Кстати, если я не ошибаюсь (я плохо знаю про ACPI), то основная задача ACPI - выключение/выключение/замораживание устройств и их настройка (распределение прерываний, выбор режима работы etc), которые не так уж и критичны к скорости. То есть если мы вынесем их в ядро их производительность повыситься, но толку от неё будет не много (потому что для большинства этих операций время выполнения несколько десятков или даже сотен миллисекунд не критично, потому что сама по себе операция выполняется редко). А вот, например, драйвер видео-карты более критичен к скорости, но его мы вынесем из ядра, потому что в подавляющем большинстве случаев его перезапуск возможен (если только устройство не перешло в состояние, когда ему поможет только перезагрузка или сгорело).

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

Что же касается API микроядра, то тут тоже имеются определённые проблемы. Конечно, память и прерывания есть на всех существующих архитектурах, только вот реализованы они не всегда одинаковым образом, так что не всегда целесообразно делать их распределение а-ля ПК -- это приведёт не только к замедлению работы, но ещё и к кривизне архитектуры системы.

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

Еще хотелось бы узнать если написать на языке высокого уровня программу и скомпилировать компиляторами примерно одного качества эту программу под архитектуру x86 и arm, то 1) какая из них будет меньше весить 2) какая из них будет занимать меньше оперативы

при портировании ядра линукс, его переписывают под целевую архитектуру или как то по другому

минимум на сколько замедлится ос если ее ядро не переписывать под каждую архитектуру, а скомпилировать ядро 1 раз под унифицированную виртуальную архитектуру и при переносе на целевую архитектуру чтобы компилятор не просто компилировал а приводил виртуальную архитектуру в соответствие целевой. Что вообще проще, быстрее сделать, переписать ядро ос под новую архитектуру или написать такой компилятор?

По большинству архитектур литературы на русском либо нет вообще, либо она крайне скупа и неполноценна. По ИА-32 книг довольно много, но всякие системные штучки либо не объясняются вообще, либо объясняются очень поверхностно. Так что по-любому необходимо владеть английским в достаточной для понимания документации степени.

Что касается компиляторов, я использовал Аду под ARM (компилятор GNAT, входит в состав GCC -- общая оптимизация, кодогенерация и прочее, только разбор исходного языка, понятное дело, разный). Не скажу, что в восторге от качества кода: можно было бы лучше генерить...

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

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

Это в точку

Добавлю от себя, phantom-84 прав, он просто забыл добавить что при всех прочих равных условиях

Насколько сложно написать ХеллоВорлд и ядро ОС?

Как вы можете гарантировать безошибчность модуля(драйвера) стороннего производителя особенно если он закрыт? Особенно в свете того что майкрософт ввела сертификацию драйверов начиная по моему с Windows XP, но даже несмотря на это сертифицированный дрова попадаются оооооочень сырые и глючные, хотя они их тестируют

Это очень плохо

Я бы сказал, что не только можно, но и нужно и необходимо

Насчет ACPI, я думаю это не только прерогатива PC, но и других архитектур просто называется и работает немного по другому, поэтому API будет примерно одинаков, но его нужно строить таким образом, чтобы он гибко и безболезненно учитывал нюансы всех архитектур, чтобы этот API можно было приспособить и под вновь появляющиеся архитектуры. Я прекрасно понимаю что это сложная задача, очень сложная, но выполнимая однако.

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

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

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

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

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

Я немножко не про это спрашивал, я просил сравнить вес и размер занимаемой оперативы одной и то же программой скомпилированной под разные архитеткуры

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

Вот, вы уловили главное, для чего я затеял эту тему, БРАВО!!!!

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

Это да. Хотя как это реализовать дело ядра. Процессам предоставляются лишь механизмы сознания нитей и управление их приоритетами. И если система многопроцессорная, то ядро само должно догадаться, что процессы можно выполнять на разных ядрах и распределить их в зависимости от приоритетов. А приложениям знать о многоядерности не обязательно. Разве что иметь возможность определить их количество, чтобы создать столько же нитей для какой-то ресурсоёмкой операции. А ядро в этом случае должно догадаться, что 4 активных нити (например) неплохо было бы распределить между 4 ядрами. Если конечно же нет ещё таких же и ядер достаточно.

KIV
Я думаю, то что вы написали про многоядерность это логично, по крайней мере пока, а там может что то и поменяться

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

Какие у нас еще бывают интерфейсы пользователя кроме выше названных двух?

И еще внесу предложение о том, что ОС должна использовать не более двух колец(режим ядра и приложения), поскольку ОС планируется быть мультиархитектурной, и возможно не в каждой архитектуре предоставляется к примеру 4 кольца, как в x86 или (если я не ошибаюсь) 7 колец как в ARM, да и вообще строго говоря я абсолютно не вижу смысла в этих дополнительных кольцах, только дополнительное время будет затрачиваться на переключение между ними

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



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



Пожалуйста -- POSIX. Может работать где угодно, да и система такая как минимум одна есть -- QNX называется.



Прежде чем "не думать", ознакомьтесь с вопросом поглубже. Я не знаю, есть ли где ещё какой-нибудь аналог ACPI, но пока с таковым я не сталкивался (ну а на практике имеет смысл посмотреть только SPARC-серверы от уже бывшей Sun и IBM pServer на PowerPC). Для ARM таковых аналогов точно нет: изначально это микроконтроллер (точней, процессорное ядро для микроконтроллеров), никаких аналогов BIOS, а значит, и ACPI там нет в принципе, и для обеспечения работы ОС на разных моделях контроллеров этой архитектуры надо ручками менять набор драйверов и стартовый код системы.



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

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



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



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



Будет очень разным в зависимости от этой самой архитектуры. Кроме того, объём памяти в одних случаях играет критичекую роль, а в других -- почти никакую. Например, на современных ПК можно запустить любой изврат, который мы только сможем придумать, нескольких гигабайт ОЗУ хватит по-любому. Ну а на ARM-микроконтроллере с, например, 128 Кбайтами флэш-памяти (где должен лежать код ОС и прикладных программ) и 16 Кбайт ОЗУ?



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



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



Ещё раз: сначала изучите хотя б одну архитектуру действительно хорошо, а несколько других -- поверхностно, а потом уже "вносите предложения", поскольку сейчас Вы в основном говорите всякие глупости (чесслово, ничего личного). Нет никаких 7 колец на ARM, там всего 2 "кольца" (хотя я прекрасно понял, о чём Вы говорите), да и термин "кольцо" используется на очень малом количестве архитектур. Хотя не стану утверждать, что это выдумка Intel: подобная организация встречалась и в более ранних архитектурах, например, в VAX-11, но вроде бы не именовалась "кольцами", да и реально использовались только самый привилегированный и самый непривилегированный уровни, так что Intel просто сглупила и наступила на те же грабли, введя два лишних и никому не нужных режима. Кстати, ARM со своими разными режимами для разных категорий прерываний тоже допустила архитектурную ошибку: их наличие не упрощает, а, напротив, усложняет разработку сколько-нибудь полноценной системы. Единственное, что ARM может извинять, -- что эта фирма разрабатывала микроконтроллер, который зачастую работает без какой-либо ОС вообще, ну а в таком случае разработка действительно упрощается.

У процессора ARM есть как минимум 2 режима работы http://www.phyton.ru/pages/page41.html#energ плюс ко всему прочему эти режимы есть не только у процессора, но и у устройств, которые работают с этим процессором и нам необходимо как то управлять питанием устройств если конечно они это поддерживают