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

No comments
  • Нормальное объявление: "Организую операционную систему, недорого, в смысле от вас потребуется лишь выполнить небольшое техническое задание - все это реализовать" :) :) :)
  • Ню-ню... А переводить ОС в защищенный режим... А где планируется хранить GDT и LDT? Уж не в загрузчике ли?

    Нужно сначала писать загрузчик. Это верно. Причем, за основу можно взять стандартный кусок ядра от колибри.
    Только вот под GDT и LDT нужно зарезервировать какой-то участок памяти... Какой? Причем, было бы неплохо сначала выделить из текущего ядра загрузчик и работать над текущим ядром. Я вот сейчас еще занят изучением исходников...
  • Еще я настоятельно настаиваю на обсуждении изменений в ядре за исключением багфиксов на форуме. Я считаю, что это упростит понимание принципов построения ядра и упростит разработку, даст более четкую архитектуру.
  • А переводить ОС в защищенный режим
    а про еденичку в СR1 ничево не слышал?
    А где планируется хранить GDT и LDT?
    IDT по нулю... 2кило на весь тейбл... GDT - пару селекторов хватит (32-байта от силы, на код да данные).. LDT/TSS ф топку...
    Нужно сначала писать загрузчик
    да нах? вон - выгрузил DOS, куданить за предел базового метра. состояние запомнил. коли захочиться в рилмод вернуться если что.
    участок памяти...
    да колбасить мона где угодно - в старой доброй базовой памяти например... вон как сказал бил гатес, "640кб - хватит на всех".
  • ntoskrnl, я все понимаю... Вообще все. но... Ты не понял... Или я вообще туплю, чтоли... Существующее ядро поделить на два файла (родин ищз них загрузчик). Короче, дальше сначала написал многа, потом все стер... Когда будет результат - тогда выложу.
  • да.. не всё так сразу. Ядро Колибри довольно навороченое, тож не сразу строилось. тут нада потихоньку осиливать. просто
    прикинул простейшую модель... среду жизнеобитания, так сказать. Важен то ведь не загрузчик (loader), а сам callбасер.
  • N†OSKRNL, тебе бы всё колбаситься.
  • а какое отношение имеет эта тема к ядру Колибри?
  • Прямое. Читайте внимательнее.
  • Неинтересна тема, я сам недавно обдумывал некоторые детали работы системы. Думаю нужно детализировать всё настолько, насколько это возможно.

    Предлагаю некоторые уточнения, корректировки, оптимизации:

    - Сделать не 1, а 2 конфигурационных файла, первый для загрузки ядра и базовых драйверов(диски и системы ввода вывода такие как дисплей и клавиатура), а второй для конфигурации ядра, загрузки остальных драйверов и первой программы интерфейса пользователя у которой будет уже свой конфигурационный файл.

    - Упростить синтаксис конфигурационного файла, ос ведь на ассемблере, вот и синтаксис должен быть как в ассемблере, зачем эти лишние символы [#=;/*]:
    Файл: fdd01/boot.cfg

    Code: Select all

      name "Boot config file" 	; Обязательный параметр(идентификатор) ставиться в
      				; начале конфигурационного файла 
    
    ; Параметры для загрузчика 
    ; Приложения и драйвера для загрузки в память
    
      init 0x00080000		; С этого места будут загружаться нижеописанные файлы
    
      load "fdd01/kernel.bin"	; Загрузить ядро
      load "fdd01/kernel.cfg"	; Загрузить конфигурационный файл ядра
      load "fdd01/debug.run"	; Загрузить отладочный драйвер
      load "fdd01/video.run"	; Загрузить драйвер дисплея
      load "fdd01/keybord.run"	; Загрузить драйвер клавиатуры
      load "fdd01/hdd.run"		; Загрузить драйвер жесткого диска
         
      call 0x00080000 		; Эта строка должна быть единственная, сюда будет
      				; передано управление после загрузки всех
      				; вышеописанных файлов
    Команды 4х байтовые, для упрощения анализа.

    - Загрузчик должен перевести процессор в unreal mode, прочитать конфигурационный файл, а также всё то там написано средствами БИОС, и передать управление по указанному адресу, предварительно поместив адрес массива адресов загруженных файлов c последним элементом равным нулю в eax, в esp значение eax-4, а все остальные регистры обнулить.

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

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

    - Общедоступные куски памяти: у каждого исполняемого файла должен быть базовый адрес, а также они во время выполнения могут попросить выделить память по произвольному виртуальному адресу, что может конфликтовать с общедоступными кусками. Общедоступным кускам следует назначать уровень доступности(для текущего процесса, для драйверов и для остальных процессов), а также именовать, выдавать приложениям/драйверам только по запросу с указанием имени, адреса в виртуальном адресном пространстве данного процесса/драйвера(куда его проецировать), длины проекции, а также запрашиваемого доступа(-r -rw).

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

    - debugrun – Если не нужна отладка, можно просто закомментировать строку:

    Code: Select all

      load "fdd01/debug.run"	; Загрузить отладочный драйвер
    - Для стека выделять память доступную только для чтения и записи, для защиты от переполнений.

    Также нужно обдумать, как ядро будет выбирать какой из драйверов следует использовать. К примеру, мы загружаем универсальный драйвер, для работы с жестким диском для первого устройства, который поддерживает также и второе устройство, но для второго, мы загружаем специализированный драйвер с большим набором функций, чем в универсальном, при этом они не должны конфликтовать.
  • Угу. То есть, вы предлагаете писать с нуля, не аботая над совместимостью...?
  • Nameless wrote:Угу. То есть, вы предлагаете писать с нуля, не аботая над совместимостью...?
    Насчёт совместимости с драйверами, какая-ж тут может быть совместимость, если там они вроде закомпилированы внутрь ядра, а тут в отдельных файлах, а формат запускаемых файлов ещё вообще не обговаривался, там можно вообще сделать поддержку любого формата.
  • w-tools wrote: Синтаксис конфигурационного файла для облегчения обработки будет близок к
    синтаксису ясыка Си.

    2.1 Пример конфигурационного файла 'kernel.cfg'

    Пример конфигурационного файла:

    #name="kernel config file" // Обязательный параметр(идетификатор) ставиться в начале конфигурационного файла
    #title="Пример конфигурационного файла"; // Не обязательный параметр (заголовок)


    /* Параметры для загрузчика */
    /* Приложения и драйвера для загрузки в память*/

    #load="fdd01/kernel.bin"; // Загрузить c флоппи диска ядро (можно не писать загружается по умолчанию)
    #load="fdd01/kernel.cfg"; // Загрузить конфигурационный файл (можно не писать загружается по умолчанию)
    #load="fdd01/debug.run"; // Загрузить отладочный драйвер
    #load="fdd01/video.run"; // Загрузить драйвер дисплея (сервер)
    #load="fdd01/keybord.run"; // Загрузить драйвер клавиатуры (сервер клавиатуры)
    #load="fdd01/hdd.run"; // Загрузить драйвер жесткого диска
    #load="fdd01/mouse.run"; // Загрузить драйвер мышки (сервер мышки)
    #load="fdd01/cd-dvd.run"; // Загрузить драйвер CD-ROM, DVD-ROM
    #load="fdd01/far/far.run"; // Загрузить файловый менеджер FAR
    #load="fdd01/fasm/fasm.run"; // Загрузить ассеблер Fasm
    #load="fdd01/drv/mouse.run"; // Загрузить драйвер мышки
    #load="fdd01/tpadv/tpad.run"; // Загрузить текстовый редактор
    #load="fdd01/tcpip/tcpip.run"; // Загрузить TCP-IP драйвер(стек)
    #load="fdd01/drv/usb.run"; // Загрузить USB драйвер(стек)


    /* Параметры для ядра */

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

    /* приложения и драйвера для запуска (из памяти) */

    #run="fdd01/debug.run"; // Запустить отладочный драйвер
    #run="fdd01/video.run"; // Запустить драйвер дисплея (сервер)
    #run="fdd01/keybord.run"; // Запустить драйвер клавиатуры (сервер клавиатуры)
    #run="fdd01/hdd.run"; // Запустить драйвер жесткого диска
    #run="fdd01/mouse.run"; // Запустить драйвер мышки (сервер мышки)
    #run="fdd01/cd-dvd.run"; // Запустить драйвер CD-ROM, DVD-ROM
    #run="fdd01/far/far.run"; // Запустить файловый менеджер FAR
    #run="fdd01/fasm/fasm.run"; // Запустить ассмеблер Fasm
    #run="fdd01/drv/mouse.run"; // Запустить драйвер мышки
    #run="fdd01/tpadv/tpad.run"; // Запустить текстовый редактор
    #run="fdd01/tcpip/tcpip.run"; // Запустить TCP-IP драйвер(стек)
    #run="fdd01/drv/usb.run"; // Запустить USB драйвер(стек)
    Помоему тут лучше заюзать XML лину вроде. Благо для его расшифрования давно есть DOM и проч.

    <?xml version="1.0" encoding="UTF-8"?>
    <config name="kernel config file">

    <loader>
    <load>
    <kernel location="fdd01/kernel.bin"/>
    <drivers dir="fdd01/sys/drivers/" configdir="fdd01/sys/config">
    <driver name="debug" location="debug.drv"/>
    <driver name="dispay"
    location="display.drv"
    config="video.conf" />
    <driver name="hdr_main"
    location="hdrmain.drv"
    config="hdr.conf"/>
    <driver name="hdr_ext"
    location="hdrext.drv"
    config="hdr.conf"/>
    ...................................................................
    </drivers>
    </load>

    <kernel_config>

    <memory_dispatcher config="fdd01/sys/config">
    <vmem config="virtualmemory.conf">
    <swapping>
    <startsector value="0x01000000"/>
    <endsector value="0x05000000"/>
    </swapping>
    .............................................
    </memory_dispethcer>

    <task_dispatcher config="fdd01/sys/config/task_dispetcher"/>

    <demons>
    <demon name="time_server"
    location="fdd01/sys/service/time.exe"
    config="config="fdd01/sys/config/time_server.conf">
    <demon name="net_service">
    <location>fdd01/sys/service/nettask.exe</location>
    <protocol drv="fdd01/sys/service/tcpip.drv"
    status="active"/>
    <protocol drv="fdd01/sys/service/ipxspx.drv"
    status="passive"/>
    </demon>
    ................................................
    </demons>


    <shell config="fdd01/sys/config">
    <location>fdd01/sys/shell/winengine.exe</location>
    <location>fdd01/sys/shell/comand.exe</location>
    <textmode status="off" width="80" heiht="25"/>
    <graphmode status="onn" config="video.conf">
    </shell>
    </kernel_config>

    </loader>

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

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

    Короче все сие можно в общем прикрутить к колибри. Только заниматся этим по всей видимости никто не будет, ибо исходники колибри на 60-70% это исходники минуэта, в которых черт ногу сломит. Так что ежели переписывать все на С++ тогда пожалуй сие очень даже подойдет.

    з.ы. Я суда в ксмл прикрутил настройку тестового режима, спопинга виртуальной памяти в общем все чего нет но нужно. Короче все сие мое личное ИМХО не нравится дело ваше можете меня материть.
    Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.
  • Матерю :-).

    Во первых. Если ты решил использовать XML (а не схожий язык разметки), то используй DTD, а лучше пространства имен, а значит и обработчик, который будет жевать этот XML должен иметь валидатор (для XSD) и уметь работать с известными схемами и с неизвестными. Я по опыту скажу - лучше удавиться. Получится может не очень большой код, но очень сложный.

    Во вторых, если начнется переход на Си(++), я начну переходить на L4 ядра, Minix3 или другие. Под этими ядрами сделано значительно больше и переписывать их не вижу смысла. Я по природе не мазахист. Тот же XviD проигрыватель я делаю не переписыванием Си кода XviD на Pascal, а линковкой уже скомпилированного. Потому что какой смысл. Если тебе очень нравится Си (я не имею возражений). Возми тот же минимальный L4Ka::Pistachio и дополняй его серверами что бы получить обратную совместимость с текущей версией KolibriOS. Я думаю все скажут тебе спасибо.

    ..bw
  • Who is online

    Users browsing this forum: No registered users and 2 guests