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

No comments
  • Serge,
    Для Микро Ядра никакой видережим (не графический, не текстовый) не нужен см. функции микроядра. Все эти режимы будут инициировать и использовать драйвера по мере необходимости для пользователя.
    Об этом уже в скользь упомянал, Phantom-84

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

    У микроядра будет свой общедоступный на чтение буфер куда он будет скидывать свои отладочные сообщения и при желании можно будет включить текстовый режим вывода их на дисплей. Но это тоже не имеет ни какого отношения к функциям микроядра, так как эта мера вынужденная и нужна лиш для того чтобы визуально отладить микроядро и какие нибудь драйвера. Эта возможнасть прописана в конфигурационном файле:

    #startmsg="ON" // включить вывод информации о процессе загрузки ядра
    #debug="ON" // включить накопление в ядре отладочной информации
    #debugrun="ON" // включить вызов драйвера 'debug' про любому событию в системе

    и тому подобные параметры.

    Тем более планируется паралельно с микроядром писать 'консольный - отладочный - драйвер - дебаггер' под названием 'debug.run'

    Но этот дебаггер тоже к системе (микроядру) никак не относится и нужен только для удобства и простоты отладки ядра, драйверов и приложений.


    Phantom-84,
    Грамотное распределение данных в памяти (секционирование так сказать) и способ их хранения в памяти целиком ляжет на плечи программиста :-) :-) :-)
    Для констант и относительно статичных данных программист сможет использовать при желании тело самого файла, а для жутко 'динамичных' переменных c 'плавающей' длиной предназначен механизм выделения кусков памяти (буферов) см. функции микроядра.


    Serge,
    Вы с Ghost-ом эксперементировали с разными способами системных вызовов (с двумя типами)
    Поясни пожалуиста по подробнее какими результатами они закончились и если не сложно поясни более подробно режим вызова системных функций в BCD системах. (третий способ)


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

    Значит по умолчанию система ( именно система а не ядро) будет текстовая.

    Твое описание ядра это описание API со стороны прикладного программиста. Но вопросы внутреннего устройства ядра совершенно не ясны. Похоже ты так и не разобрался с работой i386 и мы говорим на разных языках.
    Про системные вызовы в BСD (или BSD ?) я ничего не знаю, а в Колибри результаты такие:

    для быстрых вызовов требуется плоская организация памяти.
    в среднем fastcall в 2-2.5 быстрее прерывания
    АМД тратит на вызовы и прерывания меньшее количество тактов по сравнению с Интел
    sysenter/sysexit на АМД выполняется почему-то быстрее чем syscall/sysret
    syscall/sysret есть только на АМД
    быстрые вызовы есть не на всех процессорах
  • Приветствую всех уважаемые товарисчи !!!

    Мне случайно попалась ссылочка:
    http://www.vak.ru/

    Полазив там по "проектам" особенно "UoS" и "электронный эмулятор флопика" - получил очень глубокие впечатления.

    Воистину 'Intel + IBM + Microsoft' - маст дай !!!
    Доздравствует народное творчество умельцев !!!

    P.S. без коментариев .......... :-) :-) :-)
  • Serge,

    1. Ни система загрузки ни ядро изначально не будут не текствыми не графическими, вывод на дисплей текста загрузчиком и ядром - суть только опция облегчающая отладку !!!
    (графичность или текстовость операционной системы, или и то и другое определяется исключительно загружаемым драйвером дисплея)

    2. Какие конкретно вопросы и тонкости внутреннего устройства ядра тебя интересуют ???
    Пожалуиста перечисли подробно и по пунктам.
    (иначе действительно получается что мы разговариваем на разных языках :-) )
  • w-tools

    Хорошо повторю ещё раз.

    Как будет организовано адресное пространство системы, управление памятью, обработка прерываний, планирование и переключение задач, обмен IPC ?
  • Serge
    Не мешай людям набивать свои шишки. Без этого никак. :-)
    Опыт есть величина собственная и воспринимаемая в большинстве случаев тобою самим, но никак не другими.
  • Почему я спрашивал где эти таблицы будут располагаться? Не по тому ведь что я из хочу расположить на диске или в видеопамяти, а потому, что они должны должны быть на статических адресах, в пространстве памяти ядра, оно должно ими манипулировать, особенно таблицами страниц, при каждом выделении/освобождении/обращении к странице, которая находится в файле подкачки/к карте файла/даже при переключении задач, список страниц будет меняться, ядро должно заниматься этими таблицами, а не загрузчик. ;)
    1. Зачем принципиально нужен стоп фрейм ??? (размером в одну страничку или 4mb)
    2. Зачем системе нужно перехватывать обращения по нулевому адресу ???
    По нулевому адресу можно вообще поместить ядро и не парится, при обращении к адресу с большими привилегиями, по любому произойдёт Page Fault, который ядро перехватит и сообщит приложению, тем-более что это микроядро, которое поместится в несколько 4х килобайтных страничек, вместе со всеми таблицами, а планировать адресное пространство и не надо, т.к. только ядро будет располагаться по заранее определённому адресу, а всё остальное будет расположено в своём личном адресном пространстве.

    Насчёт заставлять загрузчик грузить всё через порты, через какие порты? IDE?, SCSI?, USB?, LAN?, FLOPPY?, Эмулированный контроллер, для запуска ядра и своего 32х разрядного драйвера(тоже эмулятора) или ещё непонятно какой контроллер, представляю какой монстр получится, если туда встроит поддержку всего этого :?
    Естественно на этапе загрузки микроядра все функции BIOS будут недоступны и код загрузки файлов с дискеты будет работать в 32-х разрядном режиме через порты. Но думаю это не такое большое препятствие с у четом того что многие программисты его с успехом осислили.
    Это не препятствие, это просто ИМХО не красиво, не практично, не удобно. До того, как дать возможность загрузить родной драйвер, для конкретного устройства, система должна использовать тот, что предоставлен производителем(встроенный в BIOS).
    Или ты планируешь её грузить только с дискеты?, у меня например дисковод вообще USB

    ЗЫ Предварительная загрузка приложений из конфигурационного файла мне не особо нравится, этим всем ИМХО должен заниматься драйвер запуска приложений, уже после окончания загрузки систему(инициализации всех драйверов).
  • Serge,
    Детальное - побайтное распределение памяти, я действительно не могу описать, потому что еще до конца не разобрался в хитросплетениях таблиц которые сопутствуют страничной адресации i386 и не знаю всех 'дырок' в физической памяти платформы IBM

    А с другой стороны, если бы я знал все тонкости и хитросплетения защищенного режима, Serge как ты думаеш, я бы затевал этот топик в форуме ??? Просил бы с каждого по 'коду' ??? И в частности просил бы помощи у тебя ??? !?!?!?

    Windows, Linux, Meos, Kolibri и т.д писал не один человек, а группа единомышленников помогая друг другу, а не обвиняя и 'зарубая' идеи друг друга !!!

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

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

    Универсальный загрузчик кторый будет уметь грузить систему с IDE, SCSI, USB, LAN, FLOPPY (и т.д.) действительно будет монстровый, да и не кчему такая универсальность. Имеет смысл сделать несколько разных загрузчиков, но это уже будущее.
    А вот к флопику при начальной загрузке придется обращаться действительно через порты in, out :-) хоть это и не красиво :-) (тем более это будет наработкой для драйвера FDD)

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

    Но научить начальный загрузчик создавать эти 'контейнеры' всеже думаю следует, хотя можно наверное загрузить все сплошным массивом с дискеты, а ядро само раскидает все по 'контейнерам'

    P.S. Усиленно читаю 'доки' по защищенному режиму !!! :-) :-) :-)
  • Код ядра должен быть в адресном пространстве ("контейнере") каждого процесса, иначе система проработает до первого прерывания, так что надо определиться или ядро с нулевого адреса а приложение выше или наоборот.
  • На функций BIOS-а особо пологаться не нужно, а нужно уходить от них 'как можно дальше' По моему мнению BIOS-ы взяли слишком много 'ответственности' на себя и не справляются с довольно динамичными изменениями в сфере производства оборудования.
    Зря. Они дают совместимость. Если хотите стабильности - почему нет?
    Универсальный загрузчик кторый будет уметь грузить систему с IDE, SCSI, USB, LAN, FLOPPY (и т.д.) действительно будет монстровый, да и не кчему такая универсальность. Имеет смысл сделать несколько разных загрузчиков, но это уже будущее.
    А вот к флопику при начальной загрузке придется обращаться действительно через порты in, out хоть это и не красиво (тем более это будет наработкой для драйвера FDD)
    А можно сначала загрузить все в память (да хотябы через int15h), а потом уже переходить в защищенный режим...
    Код ядра должен быть в адресном пространстве ("контейнере") каждого процесса, иначе система проработает до первого прерывания, так что надо определиться или ядро с нулевого адреса а приложение выше или наоборот
    Я думаю, ядро с нуля надо...
  • Предварительная загрузка драйверов и приложений из конфигурационного файла мне лично тоже не очень нравиться, но я склоняюсь к мнению что такую возможность нужно обязательно сделать. Конечно это однозначно усложнит начальный загрузчик, зато можно будет загрузить систему и больше вообще не обращаться к дисковым носителям и не загружать соответствующих драйверов.
    То-есть ты хочешь отделить систему от ядру и засунуть её в загрузчик, который потом выгрузить, я тебя правильно понял?
    А зачем тогда тебе вообще писать загрузчик? Допиши к ядру Колибри прочитать всё что ты хочешь уже готовыми драйверами в 32х битном режиме, в том числе и ядро, и окажешься в точно такой-же ситуации как и после описанного тобой загрузчика, сразу-же можно запускать ядро, прямо по верх ядра Колибри.

    Короче, всё понятно, не буду мешать созданию системы)))
  • -1 (чел :) )

    А вообще это мой вариант отстранения от чужих дел! Жаль, что я его вовремя не запотентовал :)
  • По 'трындели' по 'умничали' и разбежались :-) :-) :-)

    Ха! -Ха! :-(
  • Все как всегда...
    Как я уже говорил тема до боли похожа на несколько бывших и несостоявшихся идей. Рассуждать гораздо легче, чем делать.
    Не сочтите за поучение.
  • Who is online

    Users browsing this forum: No registered users and 2 guests