Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс май 28, 2017 11:26 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 20 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Ср июн 17, 2009 11:52 am 
В общем дело было уже год назад и закончилось ступором. В курсе были только три человека: я, Diamond и <Lrz>.
В файле выложены предварительные наброски по реализации микроядра.
Внимание! Это только наброски и я не готов отвечать на сложные и каверзные вопросы.
Так что читаем, думаем, вкурваем, всасываем и излагаем свое видение данного вопроса, но только без лишних понтов и страшенных терминов. Таненбаум вот все по человечески описывает, а у нас специалисты любят терминами бросаться и ничего не объяснять.
Чтобы не было проблемы с открытием документа выложен в 6-и форматах, внутри архива.
Вложение:
Комментарий к файлу: Собственно сам документ
New_OS_project.7z [123.77 КБ]
148 скачиваний


Вернуться к началу
   
СообщениеДобавлено: Ср июн 17, 2009 12:02 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

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


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 1:03 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Mario

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

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

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


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 1:18 pm 
Serge
Цитата:
У-у-у, как у вас все запущено!

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

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

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

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

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


Вернуться к началу
   
СообщениеДобавлено: Ср июн 17, 2009 1:39 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт мар 01, 2007 4:16 pm
Сообщения: 426
А предполагается поддержка уже написанного софта, бинарная или на уровне компиляции?

..bw


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 1:44 pm 
bw
Цитата:
1.3.3 Запуск процесса отвечающего за загрузку и запуск пользовательских процессов: сервера API и рабочая среда (текстовая оболочка по типу bash или графическая любого типа).

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


Последний раз редактировалось Mario Ср июн 17, 2009 1:48 pm, всего редактировалось 2 раза.

Вернуться к началу
   
СообщениеДобавлено: Ср июн 17, 2009 1:44 pm 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 85
Serge писал(а):
И клиенты/серверы всё время должны их сами проверять ?

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


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 2:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
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()


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

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


Вернуться к началу
   
СообщениеДобавлено: Ср июн 17, 2009 3:01 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Mario
Цитата:
ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.

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


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 3:20 pm 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 85
Serge писал(а):
У каждого процесса есть набор флагов которые определяют состояние процесса.

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


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 4:31 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
tsdima

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

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

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


Вернуться к началу
СообщениеДобавлено: Ср июн 17, 2009 5:56 pm 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 85
Serge писал(а):
В Миникс и моём описании процесс и поток - синонимы.

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

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

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


Вернуться к началу
СообщениеДобавлено: Вс сен 27, 2009 4:21 pm 
Не в сети

Зарегистрирован: Вс фев 04, 2007 2:07 pm
Сообщения: 176
Можно проконсультироваться у Олега Фёдорова(legos). У него был микроядерный проект: FOS.


Вернуться к началу
 Заголовок сообщения: отзывы 2
СообщениеДобавлено: Пн сен 27, 2010 8:40 pm 
От модератора: Некоторые посты были перемещены в эту тему, чтобы не разводить здесь оффтоп. Просьба не удивляться цитированию несуществующего поста.

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

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

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


Вернуться к началу
   
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 20 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB