Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Jul 23, 2019 6:08 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 20 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Wed Jun 17, 2009 11:52 am 
В общем дело было уже год назад и закончилось ступором. В курсе были только три человека: я, Diamond и <Lrz>.
В файле выложены предварительные наброски по реализации микроядра.
Внимание! Это только наброски и я не готов отвечать на сложные и каверзные вопросы.
Так что читаем, думаем, вкурваем, всасываем и излагаем свое видение данного вопроса, но только без лишних понтов и страшенных терминов. Таненбаум вот все по человечески описывает, а у нас специалисты любят терминами бросаться и ничего не объяснять.
Чтобы не было проблемы с открытием документа выложен в 6-и форматах, внутри архива.
Attachment:
File comment: Собственно сам документ
New_OS_project.7z [123.77 KiB]
Downloaded 246 times


Top
   
PostPosted: Wed Jun 17, 2009 12:02 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
В рамках этой работы был спроектирован код и разработана связка первичного - вторичного загрузчика. viewtopic.php?f=9&t=1158
Код вторичного загрузчика почти готов, по субъективным пречинам я не смог дописать код в срок. Но уже сейчас можно загружать файл/файлы в реальном режиме и передавать им управление, причем, список того, что нужно загрузить берется из текстового файла загрузки. Я постараюсь в ближайшее время выложить документацию на структуру вторичного загрузчика. При наличии времени можно дописать динамическое формирование рам диска в область ОЗУ.


Top
   
PostPosted: Wed Jun 17, 2009 1:03 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

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

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

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


Top
   
PostPosted: Wed Jun 17, 2009 1:18 pm 
Serge
Quote:
У-у-у, как у вас все запущено!

Оставляю без комментариев, поскольку списываю на эмоциональный бзик.
Quote:
То есть все эти ТСО/БДСО работают как очереди запросов ?

Да.
Quote:
И клиенты/серверы всё время должны их сами проверять ?

А как ты себе представляешь? Вот идешь ты по улице, идешь с закрытыми глазами, заткнутыми ушами - рядом идет поводырь, который тебе сообщает когда надо остановиться и когда надо повернуть?
Quote:
А сделать традиционную схему блокирующих Send->Recieve->Replay нельзя ?

А когда это она стала традиционной? Мы имеем так много микроядер, что хоть седалищем кушай?

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


Top
   
PostPosted: Wed Jun 17, 2009 1:39 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
А предполагается поддержка уже написанного софта, бинарная или на уровне компиляции?

..bw


Top
   
PostPosted: Wed Jun 17, 2009 1:44 pm 
bw
Quote:
1.3.3 Запуск процесса отвечающего за загрузку и запуск пользовательских процессов: сервера API и рабочая среда (текстовая оболочка по типу bash или графическая любого типа).

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


Last edited by Mario on Wed Jun 17, 2009 1:48 pm, edited 2 times in total.

Top
   
PostPosted: Wed Jun 17, 2009 1:44 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Serge wrote:
И клиенты/серверы всё время должны их сами проверять ?

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


Top
   
PostPosted: Wed Jun 17, 2009 2:42 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario
Quote:
А когда это она стала традиционной? Мы имеем так много микроядер, что хоть седалищем кушай?

Здесь два десятка микроядер. А вообще их больше чем монолитных.

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

Ну тогда небольшая лекция. Как это сделано у Таненбаума / 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()


Top
   
PostPosted: Wed Jun 17, 2009 2:50 pm 
Serge
Работу планировщика я пока не рассматривал в деталях. Спасибо за объяснения.
Вообще начиная с нового года эта тема повисла в воздухе, я просто выложил то что наработал и намыслил до этого.
Так что не зря написал прилагательное "предварительные" - вообще еще копать и копать.
Брать готовое ядро - я этого не приемлю. Изучить опыт - да полезно и нужно.
Quote:
И в QNX крутится с модификациями с самого начала т.е с 80-х годов.

ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.


Top
   
PostPosted: Wed Jun 17, 2009 3:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario
Quote:
ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.

Есть много вариантов реализации с разными модификациями. Очень рекомендую посмотреть исходники Minix 3 почитать L4 Kernel Reference Manual Version X.2


Top
   
PostPosted: Wed Jun 17, 2009 3:20 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Serge wrote:
У каждого процесса есть набор флагов которые определяют состояние процесса.

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


Top
   
PostPosted: Wed Jun 17, 2009 4:31 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
tsdima

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

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

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


Top
   
PostPosted: Wed Jun 17, 2009 5:56 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Serge wrote:
В Миникс и моём описании процесс и поток - синонимы.

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

Serge wrote:
Можно обрабатывать и несколько запросов....

Можно и так. Получим RPC. В принципе, довольно неплохо, если будет возможность обращаться к сервисам на других компьютерах :)


Top
   
PostPosted: Sun Sep 27, 2009 4:21 pm 
Offline

Joined: Sun Feb 04, 2007 2:07 pm
Posts: 178
Можно проконсультироваться у Олега Фёдорова(legos). У него был микроядерный проект: FOS.


Top
   
 Post subject: отзывы 2
PostPosted: Mon Sep 27, 2010 8:40 pm 
От модератора: Некоторые посты были перемещены в эту тему, чтобы не разводить здесь оффтоп. Просьба не удивляться цитированию несуществующего поста.

Serge wrote:
Проблема Колибри не в том что она криво спланирована и написана как Бог на душу положит, а в ассемблере. Затраты времени на исправление и улучшение слишком велики.

Вообще-то я может и не высказал в теме, но я предполагал на ассемблере сделать только собственно само микроядро. Его потом можно обвешивать чем Бог на душу положит - хоть Си, хоть чем еще угодно в виде процессов-серверов и процессов-клиентов. Зато при переписывании на другую архитектуру менять придется только собственно самом маленькое микроядро. Для встроенных решений наоборот можно будет переписать нужные процессы-сервисы на ассемблер. Итого имеем масштабируемую системы от мала до велика. Если какой-то процесс-сервер написанный на ЯВУ работает недостаточно быстро его можно при желании переписать на ассемблер.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 20 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited