Page 1 of 2

Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 11:52 am
by Mario
В общем дело было уже год назад и закончилось ступором. В курсе были только три человека: я, Diamond и <Lrz>.
В файле выложены предварительные наброски по реализации микроядра.
Внимание! Это только наброски и я не готов отвечать на сложные и каверзные вопросы.
Так что читаем, думаем, вкурваем, всасываем и излагаем свое видение данного вопроса, но только без лишних понтов и страшенных терминов. Таненбаум вот все по человечески описывает, а у нас специалисты любят терминами бросаться и ничего не объяснять.
Чтобы не было проблемы с открытием документа выложен в 6-и форматах, внутри архива.
New_OS_project.7z (123.77 KiB)
Собственно сам документ
Downloaded 505 times

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 12:02 pm
by <Lrz>
В рамках этой работы был спроектирован код и разработана связка первичного - вторичного загрузчика. viewtopic.php?f=9&t=1158
Код вторичного загрузчика почти готов, по субъективным пречинам я не смог дописать код в срок. Но уже сейчас можно загружать файл/файлы в реальном режиме и передавать им управление, причем, список того, что нужно загрузить берется из текстового файла загрузки. Я постараюсь в ближайшее время выложить документацию на структуру вторичного загрузчика. При наличии времени можно дописать динамическое формирование рам диска в область ОЗУ.

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 1:03 pm
by Serge
Mario

У-у-у, как у вас все запущено! :)

То есть все эти ТСО/БДСО работают как очереди запросов ?
И клиенты/серверы всё время должны их сами проверять ?

А сделать традиционную схему блокирующих Send->Recieve->Replay нельзя ?

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 1:18 pm
by Mario
Serge
У-у-у, как у вас все запущено!
Оставляю без комментариев, поскольку списываю на эмоциональный бзик.
То есть все эти ТСО/БДСО работают как очереди запросов ?
Да.
И клиенты/серверы всё время должны их сами проверять ?
А как ты себе представляешь? Вот идешь ты по улице, идешь с закрытыми глазами, заткнутыми ушами - рядом идет поводырь, который тебе сообщает когда надо остановиться и когда надо повернуть?
А сделать традиционную схему блокирующих Send->Recieve->Replay нельзя ?
А когда это она стала традиционной? Мы имеем так много микроядер, что хоть седалищем кушай?

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

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 1:39 pm
by bw
А предполагается поддержка уже написанного софта, бинарная или на уровне компиляции?

..bw

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 1:44 pm
by Mario
bw
1.3.3 Запуск процесса отвечающего за загрузку и запуск пользовательских процессов: сервера API и рабочая среда (текстовая оболочка по типу bash или графическая любого типа).
Все на уровне серверов обеспечиающих эмуляцию API любой другой ОС, в том числе Колибри.
Возможно потребуются некоторые незначительные изменения, а возможно нет. По крайней мере есть перед глазами пример работающего Miraculix, который обеспечивает запуск некоторых приложений Menuet.

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 1:44 pm
by tsdima
Serge wrote:И клиенты/серверы всё время должны их сами проверять ?
Нет. В ядре должна быть функция, аналогичная виндовой WaitForSingleObject, которая, в случае если надо ждать, усыпляет текущий процесс и передаёт управление дальше "по карусели". Соответственно, когда очередь доходит до процесса, который ждал семафора, планировщик должен проверить значение этого семафора, и в зависимости от значения (а если требуется, и от наличия таймаута) либо "крутить карусель" дальше, либо передать управление процессу, и для процесса это будет выглядеть как возврат из функции WaitForSingleObject.

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 2:42 pm
by Serge
Mario
А когда это она стала традиционной? Мы имеем так много микроядер, что хоть седалищем кушай?
Здесь два десятка микроядер. А вообще их больше чем монолитных.

Схема Send->Recieve->Replay наверняка старше чем Minix. И в QNX крутится с модификациями с самого начала т.е с 80-х годов.
А как ты себе представляешь? Вот идешь ты по улице, идешь с закрытыми глазами, заткнутыми ушами - рядом идет поводырь, который тебе сообщает когда надо остановиться и когда надо повернуть?
Ну тогда небольшая лекция. Как это сделано у Таненбаума / QNX. Без описания передачи данных - в данном случае это не принципиально.

Есть очередь планировщика. В ней находятся процессы (потоки) готовые к исполнению. У каждого процесса есть набор флагов которые определяют состояние процесса.
"Ready" процесс выполняется или готов к исполнению и находится в очереди планировщика.

"Send blocked" - процесс ожидает отправки сообщения.
"Recieve blocked" - процесс ожидает получения сообщения.
"Replay blocked" - процесс ожидает ответа на сообщение.

В любом из этих состояний процесс исключается из очереди планировщика и никогда не получит управление.

Каждый процесс хранит список процессов обратившихся с запросами.

Как работает IPC.

Клиент вызывает Send();
Если адресат (сервер) готов к приёму IPC (т.е. находится в состоянии "Recieve blocked") то клиент переходит к ожиданию ответа "Replay blocked" и исключается из очереди планировщика. У сервера сбрасывается "Recieve blocked" и если другие блокирующие флаги не установлены то он переходит в состояние "Ready" и помещается в очередь планировщика.

Если адресат не готов к приёму IPC клиент переходит в состояние "Send blocked", исключается из очереди планировщика и помещается в список запросов адресата.

Со стороны сервера:

Сервер вызывает Recieve().
Если в его списке есть процесс ожидаещий отправки IPC ("Send blocked") то этот процесс переходит в состояние "Replay blocked" и исключается из списка.
Если список пуст (нет ожидающих процессов) то сервер переходит в состояние "Recieve blocked"

Сервер вызывает Replay().

Если адресат находится в состоянии "Replay blocked" то состояние сбрасывается и и если другие блокирующие флаги не установлены то он переходит в состояние "Ready" и помещается в очередь планировщика.

В микроядре L4 v2 все эти функции Send() Recieve() Replay() ReplyWait() очень оригинально сделаны на базе одного системного вызова Ipc()

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 2:50 pm
by Mario
Serge
Работу планировщика я пока не рассматривал в деталях. Спасибо за объяснения.
Вообще начиная с нового года эта тема повисла в воздухе, я просто выложил то что наработал и намыслил до этого.
Так что не зря написал прилагательное "предварительные" - вообще еще копать и копать.
Брать готовое ядро - я этого не приемлю. Изучить опыт - да полезно и нужно.
И в QNX крутится с модификациями с самого начала т.е с 80-х годов.
ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 3:01 pm
by Serge
Mario
ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.
Есть много вариантов реализации с разными модификациями. Очень рекомендую посмотреть исходники Minix 3 почитать L4 Kernel Reference Manual Version X.2

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 3:20 pm
by tsdima
Serge wrote:У каждого процесса есть набор флагов которые определяют состояние процесса.
При синхронной отправке запроса/получении ответа, как я полагаю, всё это будет медленно работать. И к тому-же, не будет возможности обрабатывать несколько запросов одновременно. Хочется ещё добавить, что наличие внутри процесса нескольких потоков (каждый из которых может находиться в состоянии ожидания) - это вполне естесственно, и это нужно учесть при проектировании ядра. Если не нравится терминология "процесс-потоки", можно обозвать это несколькими процессами с общим адресным пространством.

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 4:31 pm
by Serge
tsdima

В Миникс и моём описании процесс и поток - синонимы.
При синхронной отправке запроса/получении ответа, как я полагаю, всё это будет медленно работать. И к тому-же, не будет возможности обрабатывать несколько запросов одновременно
IPC конечно медленнее простого вызова ядра, но если постараться то будет работать достаточно быстро.

Можно обрабатывать и несколько запросов. Я описал самый общий вариант. Фактически это удалённый вызов функции сервера. В L4 он называется Call().
Во всех вызовах присутствует время ожидания. Вызов Recieve(timeout=0) просто проверяет входящие запросы без блокировки. В этом случае сервер файловой системы может организовать внутреннюю очередь запросов и переупорядочивать их по своему усмотрению. Есть Send() без ожидания ответа и Notify() и т.п.

Re: Предварительные наброски по проектированию микроядра

Posted: Wed Jun 17, 2009 5:56 pm
by tsdima
Serge wrote:В Миникс и моём описании процесс и поток - синонимы.
Я согласен, терминология - не главное. Однако возможность сосуществования нескольких процессов/потоков в одном адресном пространстве лишней не будет. Если они будут расположены в "карусели" рядом (а это необходимо), то при переключении между ними не нужно будет менять адресное пространство, в итоге получим выигрыш в скорости. К примеру, можно запустить несколько сервисов в пределах одного адресного пространства (в винде это svchost.exe).
Serge wrote:Можно обрабатывать и несколько запросов....
Можно и так. Получим RPC. В принципе, довольно неплохо, если будет возможность обращаться к сервисам на других компьютерах :)

Re: Предварительные наброски по проектированию микроядра

Posted: Sun Sep 27, 2009 4:21 pm
by Maxis
Можно проконсультироваться у Олега Фёдорова(legos). У него был микроядерный проект: FOS.

отзывы 2

Posted: Mon Sep 27, 2010 8:40 pm
by Mario
От модератора: Некоторые посты были перемещены в эту тему, чтобы не разводить здесь оффтоп. Просьба не удивляться цитированию несуществующего поста.
Serge wrote:Проблема Колибри не в том что она криво спланирована и написана как Бог на душу положит, а в ассемблере. Затраты времени на исправление и улучшение слишком велики.
Вообще-то я может и не высказал в теме, но я предполагал на ассемблере сделать только собственно само микроядро. Его потом можно обвешивать чем Бог на душу положит - хоть Си, хоть чем еще угодно в виде процессов-серверов и процессов-клиентов. Зато при переписывании на другую архитектуру менять придется только собственно самом маленькое микроядро. Для встроенных решений наоборот можно будет переписать нужные процессы-сервисы на ассемблер. Итого имеем масштабируемую системы от мала до велика. Если какой-то процесс-сервер написанный на ЯВУ работает недостаточно быстро его можно при желании переписать на ассемблер.

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