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

Kernel architecture questions
  • В рамках этой работы был спроектирован код и разработана связка первичного - вторичного загрузчика. viewtopic.php?f=9&t=1158
    Код вторичного загрузчика почти готов, по субъективным пречинам я не смог дописать код в срок. Но уже сейчас можно загружать файл/файлы в реальном режиме и передавать им управление, причем, список того, что нужно загрузить берется из текстового файла загрузки. Я постараюсь в ближайшее время выложить документацию на структуру вторичного загрузчика. При наличии времени можно дописать динамическое формирование рам диска в область ОЗУ.
  • Mario

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

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

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

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

    ..bw
  • bw
    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.
  • Serge wrote:И клиенты/серверы всё время должны их сами проверять ?
    Нет. В ядре должна быть функция, аналогичная виндовой WaitForSingleObject, которая, в случае если надо ждать, усыпляет текущий процесс и передаёт управление дальше "по карусели". Соответственно, когда очередь доходит до процесса, который ждал семафора, планировщик должен проверить значение этого семафора, и в зависимости от значения (а если требуется, и от наличия таймаута) либо "крутить карусель" дальше, либо передать управление процессу, и для процесса это будет выглядеть как возврат из функции WaitForSingleObject.
  • 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()
  • Serge
    Работу планировщика я пока не рассматривал в деталях. Спасибо за объяснения.
    Вообще начиная с нового года эта тема повисла в воздухе, я просто выложил то что наработал и намыслил до этого.
    Так что не зря написал прилагательное "предварительные" - вообще еще копать и копать.
    Брать готовое ядро - я этого не приемлю. Изучить опыт - да полезно и нужно.
    И в QNX крутится с модификациями с самого начала т.е с 80-х годов.
    ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.
  • Mario
    ЕМНИП читал что при переходе с 4 на 6-ю версию количество типов сообщений было расширено.
    Есть много вариантов реализации с разными модификациями. Очень рекомендую посмотреть исходники Minix 3 почитать L4 Kernel Reference Manual Version X.2
  • Serge wrote:У каждого процесса есть набор флагов которые определяют состояние процесса.
    При синхронной отправке запроса/получении ответа, как я полагаю, всё это будет медленно работать. И к тому-же, не будет возможности обрабатывать несколько запросов одновременно. Хочется ещё добавить, что наличие внутри процесса нескольких потоков (каждый из которых может находиться в состоянии ожидания) - это вполне естесственно, и это нужно учесть при проектировании ядра. Если не нравится терминология "процесс-потоки", можно обозвать это несколькими процессами с общим адресным пространством.
  • tsdima

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

    Можно обрабатывать и несколько запросов. Я описал самый общий вариант. Фактически это удалённый вызов функции сервера. В L4 он называется Call().
    Во всех вызовах присутствует время ожидания. Вызов Recieve(timeout=0) просто проверяет входящие запросы без блокировки. В этом случае сервер файловой системы может организовать внутреннюю очередь запросов и переупорядочивать их по своему усмотрению. Есть Send() без ожидания ответа и Notify() и т.п.
  • Serge wrote:В Миникс и моём описании процесс и поток - синонимы.
    Я согласен, терминология - не главное. Однако возможность сосуществования нескольких процессов/потоков в одном адресном пространстве лишней не будет. Если они будут расположены в "карусели" рядом (а это необходимо), то при переключении между ними не нужно будет менять адресное пространство, в итоге получим выигрыш в скорости. К примеру, можно запустить несколько сервисов в пределах одного адресного пространства (в винде это svchost.exe).
    Serge wrote:Можно обрабатывать и несколько запросов....
    Можно и так. Получим RPC. В принципе, довольно неплохо, если будет возможность обращаться к сервисам на других компьютерах :)
  • Можно проконсультироваться у Олега Фёдорова(legos). У него был микроядерный проект: FOS.
  • От модератора: Некоторые посты были перемещены в эту тему, чтобы не разводить здесь оффтоп. Просьба не удивляться цитированию несуществующего поста.
    Serge wrote:Проблема Колибри не в том что она криво спланирована и написана как Бог на душу положит, а в ассемблере. Затраты времени на исправление и улучшение слишком велики.
    Вообще-то я может и не высказал в теме, но я предполагал на ассемблере сделать только собственно само микроядро. Его потом можно обвешивать чем Бог на душу положит - хоть Си, хоть чем еще угодно в виде процессов-серверов и процессов-клиентов. Зато при переписывании на другую архитектуру менять придется только собственно самом маленькое микроядро. Для встроенных решений наоборот можно будет переписать нужные процессы-сервисы на ассемблер. Итого имеем масштабируемую системы от мала до велика. Если какой-то процесс-сервер написанный на ЯВУ работает недостаточно быстро его можно при желании переписать на ассемблер.

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

    Users browsing this forum: Ahrefs [Bot] and 4 guests