Тех. Задание на Микро-Ядро

No comments
  • Мне тоже кажется лучше использовать существующие ядра. Ядро это конечно не велосипед. Почему, например, не придерживаться протокола L4. На сколько я понимаю тогда появится возможность работать с драйверами Linux. Почему не использовать загрузчик GRUB или другие. В GRUB можно сконфигурировать загрузку ядра, драйверов и roottask.
    Что я точно знаю так это то что KOS должна быть десктопной системой, но при этои иметь развитую консоль и виртуальные и реальные терминалы (текстовые и графические). Мне кажется это минимальные требования для любой современное ОСы.
    В качестве микроядерной архитектуры я считаю лучше адаптировать существующие. Все же это более сложная вешь нежели монолиты.

    p.s. Сегодня получил книжку Таненбаума, буду образовываться :-).

    ..bw
  • Наконец в каком режиме будет работать система, текстовом или графическом ? Перейти в графический режим можно только через вызов БИОС
    Serge, не навязывай свои взгляды, тем более не совсем правильные. Активизировать графический режим еще до перехода в защищенный режим только потому, что так "проще" - это совершенно неправильный подход! Ты не допускаешь, что в защищенном режиме системе может понадобиться многократно менять графический режим?

    P.S. Графический режим, GUI и все такое тоже явно не тянут на роль фундамента, а порядок загрузки ОС (многие на него не обращают особого внимания, а зря) достаточно важен, особенно в связи с последующей загрузкой драйверов, и позволяет сразу начать что-то делать, а не только заниматься обсуждением.
  • Что бы небыло желание менять гр. режим. Должен передаваться контекст (виртуальное понятие) гр. режима (или режима дисплея) от модуля модумю. А каждый следующий сам должен думать менять режим или нет. То же касается др. оборудования. Хотя это уже выходит за рамки темы.

    ..bw
  • Serge wrote:P.S.

    Дом начинают строить с фундамента, а ты строишь крыльцо со ступеньками, загрузчик для безъядерной операционной системы, потому что никакого ядра нет и в помине, нет даже представления о том как это ядро будет устроено и как будет работать. Список желаемых функций ядра ещё не ядро. Куда это ядро должно грузиться, по каким адресам ? Как будут передаваться параметры при системных вызовах и данные между разными адресными пространствами ? Как вообще эти пространства будут устроены ?
    А вот об этом и топик... ;)
  • Эта тема до боли напоминает мне одну тему на нашем форуме, где обсуждали многоступенчатый загрузчик. Долго спорили, доказывали друг-другу преимущества некоторых подходов, а потом все как-то сошло на нет, и благополучно загнулось.
    Не буду навязывать свое мнение (хотя его размещение уже по факту является навязыванием, ну да ладно...) но ИМХО вам надо сначала определиться:
    1) На каком языке писать будете - иначе совсем не договоритесь.
    2) Возьмете готовое микроядро (minix или вот наш старый знакомый Kreoton давно уже делает свою микроядерную ось, правда с закрытыми исходниками) и доработаете или напишете полностью свое.
    Пока не будет определенности, с этими двумя вопросами, будет как в басне Крылова к сожалению.
    Удачи.
  • Кто не пробует - тот не ошибается !!!
    Кто не ошибается - тот не развивается и не совершенствуется !!!
    Кто не совершенствуется - тот начинает гнить, разлогаться и умирает !!!

    P.S. Товарисчи, товарисчи пожалуиста болше 'кода' и по меньше 'флейма '
    С уважением, w-tools...
  • Загрузчик должен сначало первести процессор в P-Mode, затем обязательно настроить
    страничную адресацию, затем выделять при помощи страничной адресации куски памяти и заносить в эти куски наши драйвера и приложения по конфигурационному файлу на загрузку.
    Где будут хранится GDT, IDT, список страниц, таблица прерываний с их обработчиками, менеджер памяти который выделяет для всего этого память? В загрузчике? Так он же будет выгружен, чтоб не занимать лишнюю память. Кому придётся оперировать со страницами и таблицами *DT? Ядру? Так оно же даже не знает где это всё находится, т.к. загрузчик по тихому выделил память разместил всё там и сленял.

    Насчёт формата приложений, думаю такой формат нужно применить драйверам, т.е. ядру заморачиваться и запуском не придётся, закинет страничку в память и передаст управление, а вот с запуском всяких левых приложений...

    Кстати, у меня идея, как осуществлять запуск приложений:
    Предположим для взаимодействия между драйверами используется их псевдоним, например у драйвера работы с файловой системой, псевдоним fs(пример обращения fs:/boot.cfg, всё что после ":" передаётся драйверу как есть, на основной файловой систему уже будут символические ссылки на другие диски и остальные носители поддерживающие файловые системы), у ssl протокола https(https://site.com/page.html, драйвер получает "//site.com/page.html"), для зупуска программ тоже нужно сделать драйвер, с псевдонимом run, когда приложение1 пытается запустить приложение2, оно посылает системный вызов ядру вида "run:fs:/notepad.run", ядро в свою очередь посылает драйверу run строку "fs:/notepad.run", тот проверяет привилегии приложения1 и делится(выполняет что-то типа никсовской команды fork) и в своей полу-копии(клонироваться будет не вся память, а только та, которая нужна для реализации, т.е. при выделении страниц, нужно добавить флаг PAGE_CLONEABLE, или снять его функцией PageProtect, т.к. он должен быть установлен по умолчанию для исполняемых элементов программы) понижает свои привилегии до приложения1, открывает файл "fs:/notepad.run", выполняет некоторые проверки и передаёт на него управление, тем временем оригинал драйвера, получивший pid клона, сразу-же, возвращает его приложению1 как результат системного вызова, таким образом, мы снимаем с ядра обязанность загружать и исполнять различные типы запускаемых файлов и создаём некую универсальность(например можно сделать драйвера с псевдонимом exe, elf и т.д.).
  • Phantom-84

    Гладко было на бумаге, да забыли про овраги...
    Да, замечательно когда драйвер может менять видеорежим, только под Linux, Windows и MacOS ATI и NVIDIA делают драйверы, а для Колибри нет. Есть видеодрайвер Транса, программирующий CRT для смены частоты и режима, но на х1600 он уже не работает. Единственный способ установить требуемый графический режим и частоту экрана - запрограммировать PLL регистры видеокарты, но для этого надо знать как это делать. Такая информация есть не для всех чипов и очень немногие могут ей воспользоваться. Такова реальность.
    Графический режим, GUI и все такое тоже явно не тянут на роль фундамента...
    Где будут хранится GDT, IDT, список страниц, таблица прерываний с их обработчиками, менеджер памяти который выделяет для всего этого память?
    Вот и я о том же. Знать порядок загрузки ядра и драйверов хорошо. Только по каким адресам это ядро будет размещаться ? Где будет хранить свои системные данные ? Как будет организовано адресное пространство системы, управление памятью, обработка прерываний, планирование и переключение задач, обмен IPC ? Это и есть фундамент. И здесь требуются не общие фразы "ядро выделяет память, ядро переключает потоки", а понимания того как это будет работать на "железе" и подробное описание алгоритмов и структур данных. А этого нет.
  • Да, замечательно когда драйвер может менять видеорежим, только под Linux, Windows и MacOS ATI и NVIDIA делают драйверы, а для Колибри нет. Есть видеодрайвер Транса, программирующий CRT для смены частоты и режима, но на х1600 он уже не работает.
    Мы ведь не драйверы пишем, а систему, для отладки и старта системы х1600 с головой хватит, у меня даже нет такого монитора, чтоб поддерживал такое разрешение. :D
    А если/когда система станет популярной и к ней драйвера писаться будут, это лишь вопрос времени.
    Вообще, для отладки, видео драйвер под S3-Trio написать, чтоб под виртуальной машиной работал, этого для начала вполне достаточно.
    Загрузчик должен сначало первести процессор в P-Mode, затем обязательно настроить
    страничную адресацию, затем выделять при помощи страничной адресации куски памяти и заносить в эти куски наши драйвера и приложения по конфигурационному файлу на загрузку.
    И ещё, после того как он включит P-Mode и страничную адресацию, он потеряет возможность читать диск, т.к. драйвера не загружены.
  • hidden
    x1600 - ATI Radeon x1600 (R520). А разрешение ходовое 1027*768 85 Гц. И его к сожалению нельзя и через БИОС установить.
    В виртуальной машине хорошо проверять алгоритмы, но настоящий комп она не заменит, особенно там где могут сказаться особенности конкретной модели процессора или другого железа.
  • Serge, а зачем ядру вообще работать с графическими режимами? Пусть для всяких там kernel panic и driver info использует текстовый режим, работа с которым стандартизирована на самом низком уровне. Кстати, работать с функциями VESA BIOS можно и в защищенном режиме, причем существует не один, а целых два способа такой работы (через 32-разрядное расширение при наличии такового и через виртуальную машину, которую, правда, еще нужно организовать).
  • Phantom-84,
    Обьясни пожалуиста по подробнее:

    1. Зачем принципиально нужен стоп фрейм ??? (размером в одну страничку или 4mb)
    2. Зачем системе нужно перехватывать обращения по нулевому адресу ???
    (Если стоп фрейм нужен только для того чтобы функциям возвращать ошибки, то это можно организовать и по другим адресам или вдругом месте и другим способом)
    3. По каким объективным причинам не следует делать содержимое файла - точной копией образа памяти ???
    (я считаю слово 'просто' есть первый шаг к слову 'надежно', а слово 'примитивно' не более чем дань 'текущей моде' и 'устоявшимся стереотипам')

    hidden,
    GDT, IDT, список страниц, таблица прерываний будет храниться в памяти компьютера (в ОЗУ) или я чегото не допонял, поясни пожалуиста.
    Начальный загрузчик (имеется виду вторичный загрузчик, не тот который сидит в бут секторе) проведет всю подготовительную работу по переключению процессора, настройке страниц, созданию таблиц прерываний, вывыделит при помощи страничной адресации куски памяти и тупо загрузит в них файлы с дисковода, винчестера, USB если это будет так сказать мульти загрузчик. На начальном этапе достаточно если он сможет загрузить файлы с дисковода из корневой директории (которые выведут на дисплей Hello World !!! :-) :-) :-) )

    Естественно на этапе загрузки микроядра все функции BIOS будут недоступны и код загрузки файлов с дискеты будет работать в 32-х разрядном режиме через порты. Но думаю это не такое большое препятствие с у четом того что многие программисты его с успехом осислили.
    После того как начальный загрузчик загрузил микро ядро и передал управление на него, в памяти все уже настроено и все доступно для ядра.
    После этого ядро может смело удалить загрузчик. Конечно все таблици и настройки остануться сидеть в памяти.

    Ядро по сути является не обработчиком, а всего лиш регистратором прерываний и хранителем сопутствующих таблиц переходов на драйвера и приложения.
    1. Регистратор прерываний таймера - типичная очеред задач для простых приложений
    2. Регитратор остальных аппаратных прерываний прерываний - для различных драверов
    3. Регистратор программных прерываний - механизм для реализации внутренних API для драйверов, DLL, и некоторых приложений

    Ядро по аппаратным прерываниям запускает те приложения и драйвера которые начальный загрузчик уже загрузил в память (эти приложения посредствам страничной адресации начальный загрузчик уже уложил в свои адресные пространства - контейнеры).
    В свою очередь драйвера и приложения после передачи управления на них , регестрируются в ядре и получают от него ресурсы:
    - прерывание или диапазон прерываний
    - порт или диапазон портов
    - кусок памяти (буфер) или несколько буферов (зависимый-независимый, общий - приватный, чтение - запись)
    - API или общедоступные буферы запущенных (загруженных) ранее драйверов

    После запуска ядра, любое приложение может запустить на выполнение новое приложение с любого диска (при наличии драйверов) или сам драйвер может запустить на исполнение файл.
    Если кому нравиться то можно написать и запустить отдельное приложение которое будет заниматьс только запуском приложений - Диспетчер Загрузок. Эти способы не принципиальны и могут работать параллельно не мешая друг другу.

    Подробнее - См. первый пост в этой теме где представлен 'скелет' минимально необходимых функций микроядра.

    Примерно одна третья часть 'минимально' необходимого загрузчика написана в этой теме. Осталось сформировать первичный загрузчик (бут рекорд) и научить вторичный загрузчик включать страничную адресацию + считывать в память файл(файлы) с дискеты в 32-x режиме.

    P.S. Продолжение следует ...
  • Phantom-84

    Вопрос к тому, какой режим для системы будет родным изначально, текстовый или графический.
  • 1. Зачем принципиально нужен стоп фрейм ??? (размером в одну страничку или 4mb)
    2. Зачем системе нужно перехватывать обращения по нулевому адресу ???
    Принципиально, не нужен, но может быть полезен в том случае, когда прикладной код по каким-то там причинам не выполнил анализ результата, полученного от некоторой функции, которая вернула ему NULL-указатель. Предположим, функция возвращает какую-то структуру, тогда при доступности первой страницы во время чтения этой структуры приложение может к примеру прочитать стартовый код, не вызвав сразу появление ошибки, а если бы эта страница была недоступна, то неизбежная в общем ошибка была сразу идентифицирована системой.
    3. По каким объективным причинам не следует делать содержимое файла - точной копией образа памяти ???
    (я считаю слово 'просто' есть первый шаг к слову 'надежно', а слово 'примитивно' не более чем дань 'текущей моде' и 'устоявшимся стереотипам')
    Причин много. Вот некоторые из них. Во-первых, далеко не вся информация в исполняемом файле может быть нужна при выполнении программы; во-вторых, в файле часто требуется хранить несколько секций, не выровненных на определенную границу в памяти и имеющих далеко не смежные адреса привязки, т.е. адреса, по которым эти секции нужно загружать в память.
  • Who is online

    Users browsing this forum: No registered users and 6 guests