Модификация ядра Kolibri OS: уточняющие вопросы

Internal structure and you change requests/suggestions
  • Основной недостаток - повторная компиляция. Но для ядра, написанного целиком на fasm'е, это не слишком существенно. Остальное решается хорошим структурированием исходников, основанным прежде всего на парадигме секций. Хотя не уверен, что в Колибри код также распределяется по секциям, как и данные, но это можно исправить.

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

    Edited. Я надеюсь, что все мы здесь под "статическими адресами" применительно к Колибри понимаем часто и просто жестко закодированные в исходниках адреса (явные или смещения к примеру относительно базы ядра).
  • Сам на FASM не писал, могу ошибаться.

    Мне кажется, что подход FASM-а похож на подход Turbo Pascal до версии 4.0. В нём ещё не было модулей (unit), а были только включаемые файлы. Зато из-за скорости компиляции временем компиляции можно было пренебречь. Объектников тоже не было, всё собиралось сразу в файл .com, ещё даже не .exe. Директивой $L можно было подключать чужие объектные файлы, а функции и процедуры описывать с модификатором external в самом Паскале.
  • В fasm'е ситуация еще хуже. Директивы типа includelib нет, т.е. подключить объектник с помощью стандартных средств невозможно. Нужно либо писать макросы для подключения объектника/экспорта/импорта (не самая простая задача), либо делать все на уровне исходников. В Колибри код объединяется с помощью включаемых файлов, а данные с помощью специальных макросов, позволяющих группировать их в бинарнике по назначению (типа инициализированные данные отдельно, неинициализированные отдельно). У меня наравне с данными группируется и код. Это позволяет код из отдельно взятого исходника записывать в разные участки бинарника (типа инициализационный код реального режима отдельно, инициализационный код защищенного режима отдельно, "основной" код отдельно).
  • FireWall wrote: Кто нибуть экспериментировал по включению кода на C (грубо говоря) в код ядра KolibriOS?
    Я чуток пробовал. Сейчас деталей не помню, но, думаю, ничего сложного. Завернуть код (и данные, ибо их никто не отделяет) ядра в отдельную секцию, написать правильно скрипт линковки и линковать с сишным кодом.

    Только надо сначала узнать, куда и как колибревый код в памяти маппится и страницами покрывается.
  • Я отказался от этой идеи (пока) так как:
    (1) Это всё-таки сложно сделать "в лоб": ядро загружается загрузочным сектором единым монолитным куском, который (а) стартует в реальном режиме процессора, устанавливая видео режим VESA, затем переходит в (б) защищённый режим процессора, включает страничное отображение и отображает себя в верхнюю память и переходит (в) в свой образ в верхней памяти : последняя и большая часть грубо говоря исполняется совсем по другим адресам, нежели начальная часть.
    (2) Любой код можно так скажем - на лету включить в ядро посредством загрузки драйвера, а его уже написать на C проще (если не ошибаюсь - MS COFF примерно соответствующий pe-i386 gcc mingw, - формате объектников по умолчанию). Если очень надо, то символ можно добавить в таблицу экспортируемых ядром символов драйверам.

    Поправлено название формата pe-i386.
    Last edited by FireWall on Mon Nov 21, 2011 6:05 pm, edited 1 time in total.
  • Да, нехаляльно писать вирусы на ЯВУ для ос почти полностью написанной на асме. Ебаныйстыд получится.
  • Phantom-84 wrote:В fasm'е ситуация еще хуже. Директивы типа includelib нет, т.е. подключить объектник с помощью стандартных средств невозможно. Нужно либо писать макросы для подключения объектника/экспорта/импорта (не самая простая задача), либо делать все на уровне исходников. В Колибри код объединяется с помощью включаемых файлов, а данные с помощью специальных макросов, позволяющих группировать их в бинарнике по назначению (типа инициализированные данные отдельно, неинициализированные отдельно).
    fasm отлично умеет компилировать в объектные файлы. А GNU LD умеет делать из них бинарники. И понимает скрипты линковки, в которых можно указывать любые адреса линковки и менять их по ходу процесса. А по секциям код и данные можно раскидать как директивами в исходниках, так и в скрипте линковки можно это проделать, хоть задавая для отдельных (групп) файлов выделенные секции в нужном порядке с нужными базовыми адресами.

    Вместо этого изобретать какие-то велосипеды с квадратными колёсами в виде макросов… Прям комсомольцы: создадим себе проблем и будем героически их преодолевать.
  • wolf.ram wrote:fasm отлично умеет компилировать в объектные файлы. А GNU LD умеет делать из них бинарники. И понимает скрипты линковки, в которых можно указывать любые адреса линковки и менять их по ходу процесса. А по секциям код и данные можно раскидать как директивами в исходниках, так и в скрипте линковки можно это проделать, хоть задавая для отдельных (групп) файлов выделенные секции в нужном порядке с нужными базовыми адресами.
    Ничего нового не услышал.
    Вместо этого изобретать какие-то велосипеды с квадратными колёсами в виде макросов… Прям комсомольцы: создадим себе проблем и будем героически их преодолевать.
    1. Сборка из исходников - это стиль fasm'а. 2. Кто мешал писать Menuet/Kolibri на асме/си, компилировать в объектники, а потом собирать при помощи ld (и компоновочного скрипта) и др. утилит в составе трехэтажного сборочного скрипта? 3. У fasm'а есть недостатки, но достоинств больше. Я выбрал сборку из исходников, потому что для проекта на ассемблере это не столь критично (чтобы выполнить полную сборку, не нужны чаепития или прогулки по улице), а кроме того позволяет формировать бинарник ядра нужного формата без использования каких-либо доп. утилит (да и сам сборочный скрипт не сильно-то нужен). К примеру у меня бинарник ядра защищен контрольной суммой и fasm сам в состоянии произвести такой бинарник непосредственно на этапе компиляции. Не хочешь париться, исходники Линукса и чашка чая тебе в руки.
  • art_zh wrote:
    maximYCH wrote:Кстати, какой смысл в memmap.inc, если существует const.inc, в котором возможно без описаний, но зато более актуальная карта памяти?
    .
    const.inc определяет только часть статических адресов ядра. И кроме них - множество других констант, не имеющих никакого отношения к адресной карте.
    mmemmap.inc - это робкая попытка документирования адресного пространства. Не очень удачная, и не всегда когеррентная реальным адресам.
    Sorry.
    А сейчас статическое адресное пространство ядра задокументированно? (и насколько это допустимо к использованию вне ядра и получится ли?)
  • Kopa
    mmemmap.inc уже сильно устарел и его можно лишь использовать для быстрого получения как устроена структура той или иной области, а адреса уже совсем другие, да и структура иногда уже отличается. Serge вносил много изменений и, я думаю, может лучше ответить на попутные вопросы.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Kopa
    Данных по абсолютным адресам практически не осталось. Со временем всё должно перейти в data32.inc. Это даёт очень хорошую экономию к памяти ядра.
  • При резервировании области данных при сборке ядра (~ больше 46500 байт перед data32.inc)
    собранное ядро не проходит полную загрузку.

    P.S. Хотел поэкспериментировать с существующими вариантами Форт в ядре системы :)
    но существующие сейчас решения от 70Кб и выше, а в сжатии при добавлении Форт в ядро пока не вижу смысла на данном этапе.
  • Who is online

    Users browsing this forum: No registered users and 7 guests