Критикуйте

Просьба покритиковать документ, на основе которого будет реализовываться микроядро. Принимаются вопросы, с целью уточнения документа и внесения ясности. http://www.asm-teach.ru/wiki/doku.php?id=архитектура_ядра

 

http://www.asm-teach.ru/wiki/doku.php?id=%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D1%8F%D0%B4%D1%80%D0%B0

 

1. Как выполняется планирование.
2. Как реализован менеджер сообщений.
...

Это не возможно. Куда тогда писать кроме стека ?

 

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

а для начала неплохо почитать исходники опенсорсных осей разных. там отличные идеи попадаются

 

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

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

механизм сообщений реализован во многих системах. в самой выни их несколько. конкретизуйте. структуры, поля, примеры, обоснования, диаграммы, графы итд

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

 

А, м.б., товарищу newMaximYCH просто хочется побыть "директором проекта"?
Читаем:

В SVN вообще нифига нет (кроме boot.asm). Одни только громкие слова какие-то опять. Года два уже прошло, а newMaximYCH так и не повзрослел, походу.

Дизайн сайта ужасен, навигация ужасна. Наверняка и крольчатина откуда-то стырена. И всё тормозиииит.
Вместо чЯта лучше бы jabber-конференцию завёл.

 

Главное это переключение задач, оно решит и сколько колец защиты нужно и многое другое.

 

М.б. не стоит так резко высказываться? А тем более ТАК (http://www.asm-teach.ru/wiki/doku.php/start?rev=1243605207&do=diff) править Wiki. Ещё раз - IP в бан, право редактирования - зарегеным, регу - уберу.
Если внимательно почитать новости, то Anrkaid обещал в ближайшие две недели уже выложить нечто похожее на ядро. Но что бы не пойти по пути KolibriOS, я остановил его, и сказал, что бы сначала продумал архитектуру. По странице http://www.asm-teach.ru/wiki/doku.php/%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B_%D1%8F%D0%B4%D1%80%D0%B0 он сможет доделать архитектуру (кстати, SadKo, если уж есть что-то конструктивное - туда).
Сайт - это ещё пока не сайт. Сайт нужен будет, когда уже будет что-то в ядре. Пока что подняты сервисы, для удобства разработчиков.
Про Jabber конференцию думал. Делаем клиент на основе gloox.

 

извини это был я. правда не хотел. еще раз извини. касательно вашего проекта скажу только что оч. смешно было читать про спонсоров и прочие дела. вы же это не серьезно?

 

Приношу извинения SadKo.
Novi4ek, ОК. Я бы предпочел уклониться от ответа. Если это возможно.

 

Я там немного подредактировал, посмотри на досуге.
А про спонсоров - действительно бред. Надо хотя бы популярность сначала приобрести, чтобы получать donations. Убери, не позорься.

 

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

 

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

 

Как грится, ржунимагу ))) Особенно насчёт "в ближайшие несколько дней там появится точное описание". Лежит у меня где-то описание архитектуры и принципов работы одного (только одного!) из компонентов OS/360 -- так называемого главного планировщика. Так вот, сие описание занимает 990 (прописью: девятьсот девяносто) страниц. Ну а описание архитектуры _всей_ системы, коего у меня нет, имеет никак не меньше 25-30 тысяч страниц. Так что ждём-с эти ближайшие дни

 

SII, +1

 

Естественно, не настолько, что бы это было абсолютно полным алгоритмом работы, но хотя бы в http://board.kolibrios.org/viewtopic.php?f=1&t=1179 таком виде.

 

Божемой, выкладывать доки на форуме - какой ужас.

 

Вопрос не ко мне

 

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

вообще, само ядро в микроядерках это усложненный момент

call [Your_OS_API_foo]

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

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

говорят, доступны исходники ядра и части модулей QNX (qnx.com)
миникс открыта, хотя и закрыта (зато описание отличное. сам таненбаум)
оберон/блюботтл открыты
п9 открыты
инферно открыты
(все микроядерки или близки к ним (композитки?), вот только с обероном/бб непонятно, хотя не исключено, что он вас очарует, особенно если вы неравнодушны к пасу/модуле)

линукс открыты, но я б с него не начинал. в текущем состоянии он похож на кашу студенческих + бронированых заплаток увешаных снаружи погремушками не меньше винды.

есть еще хурд, л4 и проч

 

_basmp_
Там неправильно это сделано. Планировщик вызывается по прерыванию от PIT програмно перезагружая контекст, регистры сохраняются в ядренном стеке, очень даже на винь похоже. Вот только если станет таймер, то станет и ось, более того медленно это. Если уж програмно реализовано, следует в конце обработки всех прерываний вызывать планировщик. Вот и главный момент в архитектуре - дно стека содержит состояние задачи в любой момент.