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

Internal structure and you change requests/suggestions
  • Компиляция ядра KolibriOS приводит к файлу размером около 140кб, в то время как в дистрибутиве примерно 80 кб: в дистрибутиве применено сжатие средствами kerpack/Kpack?
    Для приложений kpack, для ядра kerpack. Kerpack только для среды Колибри -в настоящее время без вариантов. Kpack есть не только для Колибри.
    В файле /kernel/core/syscall.inc имеется две таблицы: servetable и servetable2. Насколько я понимаю, в первую очередь используется servetable2.
    Если я не ошибаюсь, то одна из таблиц позволяет переопределять вызовы для использования драйверов.
    Насколько верны эти утверждения?
    Информация склонна устаревать, особенно для ядра и особенно за 4 года - надо смотреть в первую очередь исходники ядра.

    Вот здесь http://diamond.kolibrios.org/nightbuild/ выкладываются ночные сборки, стабильность их не всегда высока, но лучше работать с ними при написании кода, поскольку это актуальная версия.
  • В файле /kernel/core/syscall.inc имеется две таблицы: servetable и servetable2. Насколько я понимаю, в первую очередь используется servetable2.
    Mario wrote:Если я не ошибаюсь, то одна из таблиц позволяет переопределять вызовы для использования драйверов.
    Mario: Ошибаешься.

    FireWall: Обе таблицы нужны для обращения к сисфункциям из пользовательских программ.
    Для драйверов (только в Ring 0) ядро предоставляет расширенный системный сервис - см. /core/exports.inc.

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

    Для решения этой (пустяковой, в сущности) проблемки Основатель закрутил в обработчике системных вызовов карусель ротации содержимого ВСЕХ регистов общего назначения, причем раскручивать эту карусель народу приходится до сих пор.

    servetable - это рудимент оригинальной менуэтовской таблицы, жить которой (надеюсь) осталось недолго. Управление ей передается через новую таблицу servetable2 (см. поля cross_order последних явно ротируемых сисфункций 53, 58 и 63). Неявная ротация все равно сохранилась во многих местах, но теперь она более-менее оптимизирована под специфику конкретных функций.
    Так что если где-нибудь встретишь странный код типа

    Code: Select all

    mov eax, ebx
    mov ebx, ecx
    mov ecx, edx
    ....
    знай что это оно и есть.

    С возвращаемыми параметрами (если они есть) своя заморочка - внутри ядра и между ядром и драйвером они передаются в тех же регистрах.
    А из ядра в приложение их надо передавать в стеке в силу специфики входа в Ring0 по int 40 (метка i40: в core/syscall.inc).
    Обрати внимание, что "старые" (ротируемые) сисфункции имеют лишний call, а значит и стек у них будет на 4 байта глубже...
  • to FireWall
    Уточню некоторые моменты: Упаковать ядро можно и под Windows см мой пост viewtopic.php?f=23&t=1511&p=29044#p29044.
    Особенность упаковки в том, что kerpack нужно поместить на fdd, это особенность этой программы. Программа не дает никакого лога. Об успешном выполнении можно судить только по размеру сжатого ядра.

    Попробую использовать QEMU.
  • art_zh
    Mario: Ошибаешься.
    Так ведь я и не настаивал. А вообще когда я ошибаюсь - я честно признаю свои ошибки.
    (заложившего в систему, помимо всего прочего, замечательную традицию чихать на мнение коллег, если оно не совпадает с твоим собственным)
    Можно так подумать ты сам не следуешь такому же правилу. А вообще между "чихать на мнение коллег" и "отсутсвует желание реализовывать чужие идеи" есть некоторая и весьма существенная разница. Генеральное различие в политике основателия и политике сообщества Колибри - в Колибри никто не запрещает и никто не отказывается принимать уже готовый код. Это между прочим весьма существенная разница.

    <Lrz>
    Все-же KlbrInWin не совсем запуск под Виндовс (в отличие от Kpack который таки имеет настоящую версию под Виндовс) - эмуляция ведь, плюс с учетом того что его (эмулятор) некоторые антивирусы объявляют зараженным реализовать приведенную методику будет проблемно, к сожалению.
  • Mario
    Напоминает анекдот про оптимистов и пессимистов. Один считает, что стакан на половину пуст, другой, что на половину полон.
    KlbrInWin, это именно запуск используя основную Windows систему, используя эмулятор. На мой взгляд, это единственная возможность упаковать ядро, не в среде Kolibri OS.
    И все равно данная методика осуществима, несмотря на "злостное отторжение не кошерного кода KlbrInWin".
  • Я не говорил, что "не кошерно", так частное замечание о чистоте метода.
    Жаль только, что эмулятор разработчики антивирусов объявили вне закона. :(
  • Спасибо за уточнения!

    Прокомментирую только одно :

    Когда я спрашивал по поводу размера ядра, меня прежде всего интересовало, почему у меня 140кб, а в дистрибутиве 70кб (очень примерно). Я беспокоился, что разница обусловлена отладочным кодом. Для меня kerpack легче применить внутри kolibri.img , а затем перенести при помощи редактора образов дискеты. Так что kerpack в MS Windows пока не актуален.

    Пока есть ещё один уточняющий вопрос:
    Кто нибуть экспериментировал по включению кода на C (грубо говоря) в код ядра KolibriOS?

    P.S.

    Это я уже спрашиваю в контексте KolibriOS[ia-32-generic] :wink:
  • Никто не мешает писать драйвера на Си. И если я не ошибаюсь именно так Serge делал драйвера видеокарт Ати.

    Прямое включение Си кода в ядро не возможно - сомневаюсь, что Fasm скушает такой винегрет. Разве что исхитриться линковкой объектного кода, но я тут не специалист.

    А вообще исключительно по моему мнению если переписать ядро Колибри на Си оно возможно не сильно может потерять в скорости, но разбухнет в размерах и потеряет привлекательность - станет серой обыденностью. Все-же Колибри достаточно уникальная ОС.

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

    Особенно меня "впечатлило" заявление в интервью («Chaos Constructions-2010») о том что потеря отдельных объектов не смертельна для объектного кода. Было это сказано с весьма убедительным видом.
  • FireWall

    Kolibri Pe была таким экспериментом. Вполне успешным в плане компиляции. asm часть оформлялась в PE COFF и линковалась с сишным кодом. Потом всё запускалось GRUB. Порядком устаревшие исходники есть на svn в kernel/branches.
  • Цитата:
    А вообще исключительно по моему мнению если переписать ядро Колибри на Си оно возможно не сильно может потерять в скорости, но разбухнет в размерах и потеряет привлекательность - станет серой обыденностью.
    Идея состоит не в том, чтобы переписать KolibriOS на C, а в том, чтобы использовать C-версию как трамплин при переходе на другую архитектуру (хоть ту же ia-64).

    P.S.

    Вообще-то у меня есть ещё такая (возможно сомнительная с моральной точки зрения :wink: ) очень отдалённая цель - запустить графическую подсистему KolibriOS в качестве сервера в Minix3 (это отдельное приложение, поэтому "вирус GPL" не распространится на всю Minix3)
  • Мммм, как запаковать Виндовской версией kpack'a ядро? В КОСовском варианте есть галочка "Kernel", а вот как быть с виндузятским вариантом?
  • Ядро пакуется kerpack-ом.
  • Я знал, но я не нашел kerpack для Windows. Я подумал, что раз kpack в KOS имеет галочку "kernel", то его научили паковать и приложения, и ядро.
  • kerpack для Windows не делали.
  • Who is online

    Users browsing this forum: No registered users and 7 guests