Groms писал(а):
Насколько сложно написать ХеллоВорлд и ядро ОС?
Ещё раз: ХеллоВорлд -- пример того, что можно создать безошибочную программу. Сложность же создания безошибочных программ определяется рядом факторов, в том числе их размером и связями с внешним (для них) миром. Поэтому у ОС, написанной как набор сравнительно небольших модулей, куда больше шансов быть безошибочной: каждый такой модуль проще "вылизать" (а то и доказать его безошибочность
формальным образом -- небольшой объём обычно позволяет это сделать), чем в случае здоровенной системы, где куча компонентов, достаточно хаотически взаимодействующих между собой.
Цитата:
Как вы можете гарантировать безошибчность модуля(драйвера) стороннего производителя особенно если он закрыт? Особенно в свете того что майкрософт ввела сертификацию драйверов начиная по моему с Windows XP, но даже несмотря на это сертифицированный дрова попадаются оооооочень сырые и глючные, хотя они их тестируют
Представьте себе, мне _пофиг_, глючные драйвера сторонних производителей или нет. Если я их ставлю, то я их ставлю на _свой_ страх и риск. Ну а безглючность своих драйверов я гарантировать могу (когда их официально признаю безглючными, естественно). И опять-таки, я не собираюсь пихать в ядро все драйвера подряд, но только хорошо отлаженные и не вызывающие проблем, причём такие, для которых нахождение в ядре существенно повышает производительность, Вы же собираетесь вообще запретить помещать драйвера в ядро, что для меня неприемлемо категорически: существенное усложнение системы и существенное же падение производительности без каких-либо полезных качеств взамен (про то, что падение критического драйвера убьёт микроядерную систему не хуже, чем с монолитным ядром, я уже говорил).
Цитата:
KIV писал(а):
Таким образом можно разработать API, который будет одинаков на любой архитектуре - хоть на PC, хоть на сотовом телефоне.
Я бы сказал, что не только можно, но и нужно и необходимо
Пожалуйста -- POSIX. Может работать где угодно, да и система такая как минимум одна есть -- QNX называется.
Цитата:
Насчет ACPI, я думаю это не только прерогатива PC, но и других архитектур просто называется и работает немного по другому, поэтому API будет примерно одинаков, но его нужно строить таким образом, чтобы он гибко и безболезненно учитывал нюансы всех архитектур, чтобы этот API можно было приспособить и под вновь появляющиеся архитектуры. Я прекрасно понимаю что это сложная задача, очень сложная, но выполнимая однако.
Прежде чем "не думать", ознакомьтесь с вопросом поглубже. Я не знаю, есть ли где ещё какой-нибудь аналог ACPI, но пока с таковым я не сталкивался (ну а на практике имеет смысл посмотреть только SPARC-серверы от уже бывшей Sun и IBM pServer на PowerPC). Для ARM таковых аналогов точно нет: изначально это микроконтроллер (точней, процессорное ядро для микроконтроллеров), никаких аналогов BIOS, а значит, и ACPI там нет в принципе, и для обеспечения работы ОС на разных моделях контроллеров этой архитектуры надо ручками менять набор драйверов и стартовый код системы.
Цитата:
Да ACPI относится к центральным системам, но насколько я понимаю, скорость его функционирования в режиме ядра не увеличится(вернее здесь не нужна большая скорость), дак зачем раздувать ядро если в этом нет крайней необходимости? Раздувание ядра ведет к его усложнению и как следствие к сложности его модификации и дает возможность программисту наделать больше багов, чем если бы код был минималистичен
Во-первых, большая скорость нужна везде :) Конечно, сами задачи, решаемые ACPI, не требуют этой самой большой скорости, однако, если они долго выполняются, долго не сможет выполняться что-то другое -- т.е. в любом случае повышение накладных расходов ни к чему.
Ну а во-вторых, Вы (и не только Вы) смешиваете раздувание ядра и возможность помещать в него драйвера. Сам объём ядра никогда в истории не служил причиной каких-либо проблем (не считая возможности поместиться в память на конкретной машине), проблему создаёт запутанность ядра, т.е. когда оно не просто большое, а когда там всё навалено в кучу хаотически. Такое возникает при программировании без проектирования, когда возникающие сложности решаются разного рода костылями и т.п. Если же разные компоненты системы взаимодействуют друг с другом только чётко описанным образом, никаких проблем не возникает: всё остаётся обозримым, простым и понятным.
Цитата:
SII писал(а):
Но ещё раз повторюсь: мой подход заключается в том, чтобы разрешать поступать и так, и эдак, что позволит принимать решение о размещении драйвера в ядре или вне ядра в каждом конкретном случае.
Я прекрасно понимаю, что вы за свободу выбора, но такая свобода, она зачастую мешает, а не приносит благо, поэтому я за одинаковый подход ко всем драйверам, они должны быть вынесены из нулевого кольца.
Как делать Вашу систему -- это сугубо Ваше дело. Я же никогда не буду заниматься "идеально микроядерными" системами, поскольку считаю, что они не имеют реальных (а не "бумажных") преимуществ над системами с монолитным ядром.
Цитата:
Английским я владею, но на уровне школы и мне очень сложно разбираться в том что я не знаю(пытаюсь узнать) на неродном мне языке, даже переводчики не сильно помогают, потому что там иной раз такая охинея получается, что мозг вскипает.
Переводчики сразу выкидывайте и пользуйтесь исключительно своими мозгами. Освоить перевод с технического английского на хорошем уровне никаких проблем не составляет.
Цитата:
Я немножко не про это спрашивал, я просил сравнить вес и размер занимаемой оперативы одной и то же программой скомпилированной под разные архитеткуры
Будет очень разным в зависимости от этой самой архитектуры. Кроме того, объём памяти в одних случаях играет критичекую роль, а в других -- почти никакую. Например, на современных ПК можно запустить любой изврат, который мы только сможем придумать, нескольких гигабайт ОЗУ хватит по-любому. Ну а на ARM-микроконтроллере с, например, 128 Кбайтами флэш-памяти (где должен лежать код ОС и прикладных программ) и 16 Кбайт ОЗУ?
Цитата:
chizh писал(а):
В теме переносимости, которая здесь вызвала бурное обсуждение, я не разбираюсь. Но мне пришла мысль, что переносимая ОС может существовать только на бумаге. Не в смысле, что такая ОС нереализуема. Просто такая ОС должна быть написана на бумаге в виде концепции. Или, если не на бумаге, то в виде заголовочных файлов. Могут быть и описания алгоритмов (именно описание, не реализация). По сути - обычная техническая спецификация. Главное - ни какого кода.
Вот, вы уловили главное, для чего я затеял эту тему, БРАВО!!!!
В таком смысле переносимость не только возможна, но и очень желательна. Другое дело, что до абсурда её доводить не следует, да и API должен быть модульным. Если, например, речь идёт о применении ОС в микроконтроллере управления самогонным аппаратом, нахрена там графический интерфейс а-ля Висла? Там, скорей всего, вообще никаких графических дисплеев не будет за ненадобностью -- а значит, ОС для данного конкретного экземпляра и не должна содержать соответствующий API (хотя б для экономии памяти).
Цитата:
Хотелось бы еще добавить одно свойство ОС: ОС должна быть изначально ориентированна на многопроцессорные системы - здесь я думаю комментарии излишни :)
С точки зрения эффективности, одна должна собираться и в одно-, и в многопроцессорных вариантах. Поддержка многопроцессорности увеличивает объём кода, уменьшает производительность и т.п., в то же время она совершенно не нужна в микроконтроллерах, где никогда не бывает нескольких процессоров, ну и т.п.
Цитата:
И еще внесу предложение о том, что ОС должна использовать не более двух колец(режим ядра и приложения), поскольку ОС планируется быть мультиархитектурной, и возможно не в каждой архитектуре предоставляется к примеру 4 кольца, как в x86 или (если я не ошибаюсь) 7 колец как в ARM, да и вообще строго говоря я абсолютно не вижу смысла в этих дополнительных кольцах, только дополнительное время будет затрачиваться на переключение между ними
Ещё раз: сначала изучите хотя б одну архитектуру действительно хорошо, а несколько других -- поверхностно, а потом уже "вносите предложения", поскольку сейчас Вы в основном говорите всякие глупости (чесслово, ничего личного). Нет никаких 7 колец на ARM, там всего 2 "кольца" (хотя я прекрасно понял, о чём Вы говорите), да и термин "кольцо" используется на очень малом количестве архитектур. Хотя не стану утверждать, что это выдумка Intel: подобная организация встречалась и в более ранних архитектурах, например, в VAX-11, но вроде бы не именовалась "кольцами", да и реально использовались только самый привилегированный и самый непривилегированный уровни, так что Intel просто сглупила и наступила на те же грабли, введя два лишних и никому не нужных режима. Кстати, ARM со своими разными режимами для разных категорий прерываний тоже допустила архитектурную ошибку: их наличие не упрощает, а, напротив, усложняет разработку сколько-нибудь полноценной системы. Единственное, что ARM может извинять, -- что эта фирма разрабатывала микроконтроллер, который зачастую работает без какой-либо ОС вообще, ну а в таком случае разработка действительно упрощается.