В общем дело было уже год назад и закончилось ступором. В курсе были только три человека: я, Diamond и <Lrz>.
В файле выложены предварительные наброски по реализации микроядра.
Внимание! Это только наброски и я не готов отвечать на сложные и каверзные вопросы.
Так что читаем, думаем, вкурваем, всасываем и излагаем свое видение данного вопроса, но только без лишних понтов и страшенных терминов. Таненбаум вот все по человечески описывает, а у нас специалисты любят терминами бросаться и ничего не объяснять.
Чтобы не было проблемы с открытием документа выложен в 6-и форматах, внутри архива.
Предварительные наброски по проектированию микроядра
В рамках этой работы был спроектирован код и разработана связка первичного - вторичного загрузчика. viewtopic.php?f=9&t=1158
Код вторичного загрузчика почти готов, по субъективным пречинам я не смог дописать код в срок. Но уже сейчас можно загружать файл/файлы в реальном режиме и передавать им управление, причем, список того, что нужно загрузить берется из текстового файла загрузки. Я постараюсь в ближайшее время выложить документацию на структуру вторичного загрузчика. При наличии времени можно дописать динамическое формирование рам диска в область ОЗУ.
Код вторичного загрузчика почти готов, по субъективным пречинам я не смог дописать код в срок. Но уже сейчас можно загружать файл/файлы в реальном режиме и передавать им управление, причем, список того, что нужно загрузить берется из текстового файла загрузки. Я постараюсь в ближайшее время выложить документацию на структуру вторичного загрузчика. При наличии времени можно дописать динамическое формирование рам диска в область ОЗУ.
Mario
У-у-у, как у вас все запущено!
То есть все эти ТСО/БДСО работают как очереди запросов ?
И клиенты/серверы всё время должны их сами проверять ?
А сделать традиционную схему блокирующих Send->Recieve->Replay нельзя ?
У-у-у, как у вас все запущено!
То есть все эти ТСО/БДСО работают как очереди запросов ?
И клиенты/серверы всё время должны их сами проверять ?
А сделать традиционную схему блокирующих Send->Recieve->Replay нельзя ?
Serge
Я вообщето не расписывал как работают сами клиенты и серверы - я написал что они делают и приблизительную методику взаимодействия. И в данном случае это только базовое понятие - попытка разобраться, что с чем кушать и под каким соусом.
Если сможешь дополнить или предложить свою подробную картину, чтобы ее поняли другие, а не только ты сам, то это было бы замечательно.
Оставляю без комментариев, поскольку списываю на эмоциональный бзик.У-у-у, как у вас все запущено!
Да.То есть все эти ТСО/БДСО работают как очереди запросов ?
А как ты себе представляешь? Вот идешь ты по улице, идешь с закрытыми глазами, заткнутыми ушами - рядом идет поводырь, который тебе сообщает когда надо остановиться и когда надо повернуть?И клиенты/серверы всё время должны их сами проверять ?
А когда это она стала традиционной? Мы имеем так много микроядер, что хоть седалищем кушай?А сделать традиционную схему блокирующих Send->Recieve->Replay нельзя ?
Я вообщето не расписывал как работают сами клиенты и серверы - я написал что они делают и приблизительную методику взаимодействия. И в данном случае это только базовое понятие - попытка разобраться, что с чем кушать и под каким соусом.
Если сможешь дополнить или предложить свою подробную картину, чтобы ее поняли другие, а не только ты сам, то это было бы замечательно.
А предполагается поддержка уже написанного софта, бинарная или на уровне компиляции?
..bw
..bw
bw
Возможно потребуются некоторые незначительные изменения, а возможно нет. По крайней мере есть перед глазами пример работающего Miraculix, который обеспечивает запуск некоторых приложений Menuet.
Все на уровне серверов обеспечиающих эмуляцию API любой другой ОС, в том числе Колибри.1.3.3 Запуск процесса отвечающего за загрузку и запуск пользовательских процессов: сервера API и рабочая среда (текстовая оболочка по типу bash или графическая любого типа).
Возможно потребуются некоторые незначительные изменения, а возможно нет. По крайней мере есть перед глазами пример работающего Miraculix, который обеспечивает запуск некоторых приложений Menuet.
Last edited by Mario on Wed Jun 17, 2009 1:48 pm, edited 2 times in total.
Нет. В ядре должна быть функция, аналогичная виндовой WaitForSingleObject, которая, в случае если надо ждать, усыпляет текущий процесс и передаёт управление дальше "по карусели". Соответственно, когда очередь доходит до процесса, который ждал семафора, планировщик должен проверить значение этого семафора, и в зависимости от значения (а если требуется, и от наличия таймаута) либо "крутить карусель" дальше, либо передать управление процессу, и для процесса это будет выглядеть как возврат из функции WaitForSingleObject.Serge wrote:И клиенты/серверы всё время должны их сами проверять ?
Mario
Схема Send->Recieve->Replay наверняка старше чем Minix. И в QNX крутится с модификациями с самого начала т.е с 80-х годов.
Есть очередь планировщика. В ней находятся процессы (потоки) готовые к исполнению. У каждого процесса есть набор флагов которые определяют состояние процесса.
"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()
Здесь два десятка микроядер. А вообще их больше чем монолитных.А когда это она стала традиционной? Мы имеем так много микроядер, что хоть седалищем кушай?
Схема 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()
Serge
Работу планировщика я пока не рассматривал в деталях. Спасибо за объяснения.
Вообще начиная с нового года эта тема повисла в воздухе, я просто выложил то что наработал и намыслил до этого.
Так что не зря написал прилагательное "предварительные" - вообще еще копать и копать.
Брать готовое ядро - я этого не приемлю. Изучить опыт - да полезно и нужно.
Работу планировщика я пока не рассматривал в деталях. Спасибо за объяснения.
Вообще начиная с нового года эта тема повисла в воздухе, я просто выложил то что наработал и намыслил до этого.
Так что не зря написал прилагательное "предварительные" - вообще еще копать и копать.
Брать готовое ядро - я этого не приемлю. Изучить опыт - да полезно и нужно.
ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.И в QNX крутится с модификациями с самого начала т.е с 80-х годов.
Mario
Есть много вариантов реализации с разными модификациями. Очень рекомендую посмотреть исходники Minix 3 почитать L4 Kernel Reference Manual Version X.2ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.
При синхронной отправке запроса/получении ответа, как я полагаю, всё это будет медленно работать. И к тому-же, не будет возможности обрабатывать несколько запросов одновременно. Хочется ещё добавить, что наличие внутри процесса нескольких потоков (каждый из которых может находиться в состоянии ожидания) - это вполне естесственно, и это нужно учесть при проектировании ядра. Если не нравится терминология "процесс-потоки", можно обозвать это несколькими процессами с общим адресным пространством.Serge wrote:У каждого процесса есть набор флагов которые определяют состояние процесса.
tsdima
В Миникс и моём описании процесс и поток - синонимы.
Можно обрабатывать и несколько запросов. Я описал самый общий вариант. Фактически это удалённый вызов функции сервера. В L4 он называется Call().
Во всех вызовах присутствует время ожидания. Вызов Recieve(timeout=0) просто проверяет входящие запросы без блокировки. В этом случае сервер файловой системы может организовать внутреннюю очередь запросов и переупорядочивать их по своему усмотрению. Есть Send() без ожидания ответа и Notify() и т.п.
В Миникс и моём описании процесс и поток - синонимы.
IPC конечно медленнее простого вызова ядра, но если постараться то будет работать достаточно быстро.При синхронной отправке запроса/получении ответа, как я полагаю, всё это будет медленно работать. И к тому-же, не будет возможности обрабатывать несколько запросов одновременно
Можно обрабатывать и несколько запросов. Я описал самый общий вариант. Фактически это удалённый вызов функции сервера. В L4 он называется Call().
Во всех вызовах присутствует время ожидания. Вызов Recieve(timeout=0) просто проверяет входящие запросы без блокировки. В этом случае сервер файловой системы может организовать внутреннюю очередь запросов и переупорядочивать их по своему усмотрению. Есть Send() без ожидания ответа и Notify() и т.п.
Я согласен, терминология - не главное. Однако возможность сосуществования нескольких процессов/потоков в одном адресном пространстве лишней не будет. Если они будут расположены в "карусели" рядом (а это необходимо), то при переключении между ними не нужно будет менять адресное пространство, в итоге получим выигрыш в скорости. К примеру, можно запустить несколько сервисов в пределах одного адресного пространства (в винде это svchost.exe).Serge wrote:В Миникс и моём описании процесс и поток - синонимы.
Можно и так. Получим RPC. В принципе, довольно неплохо, если будет возможность обращаться к сервисам на других компьютерахSerge wrote:Можно обрабатывать и несколько запросов....
Можно проконсультироваться у Олега Фёдорова(legos). У него был микроядерный проект: FOS.
От модератора: Некоторые посты были перемещены в эту тему, чтобы не разводить здесь оффтоп. Просьба не удивляться цитированию несуществующего поста.
Я конечно понимаю, что это сложно уложить в голову, ведь все привыкли что либо ЯВУ либо Ассемблер, но гибкий путь и не надо делать все сразу на ассемблере.
Вообще-то я может и не высказал в теме, но я предполагал на ассемблере сделать только собственно само микроядро. Его потом можно обвешивать чем Бог на душу положит - хоть Си, хоть чем еще угодно в виде процессов-серверов и процессов-клиентов. Зато при переписывании на другую архитектуру менять придется только собственно самом маленькое микроядро. Для встроенных решений наоборот можно будет переписать нужные процессы-сервисы на ассемблер. Итого имеем масштабируемую системы от мала до велика. Если какой-то процесс-сервер написанный на ЯВУ работает недостаточно быстро его можно при желании переписать на ассемблер.Serge wrote:Проблема Колибри не в том что она криво спланирована и написана как Бог на душу положит, а в ассемблере. Затраты времени на исправление и улучшение слишком велики.
Я конечно понимаю, что это сложно уложить в голову, ведь все привыкли что либо ЯВУ либо Ассемблер, но гибкий путь и не надо делать все сразу на ассемблере.
Who is online
Users browsing this forum: No registered users and 1 guest