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

Internal structure and you change requests/suggestions
  • kerpack для Windows не делали.
    Спасибо, понятно.
  • лучше data32 покажи
  • Прикладываю
    Attachments
    include.zip (4.36 KiB)
    Downloaded 417 times
  • Интересно, esp ядра устанавливается на 0x3ec00, а .bss (uglobals) заканчивается на 0x413d2. При компиляции с logo стек сразу попадал в .data.
    Поздравляю maximYCH, ты обнаружил серьёзный баг в ядре.

    Update. Там ещё и gdt под раздачу попадает.

    Code: Select all

               mov   edi,0x40000
               mov   ecx,(0x90000-0x40000)/4
               rep   stosd
    Птичка слегка растолстела.
    Last edited by Serge on Sat Sep 03, 2011 7:14 pm, edited 2 times in total.
  • Код работал корректно, насколько я понимаю, в ревизии 803.
    Птичка слегка растолстела.
    Ахаха, убила фраза, хз почему.
    Ты имеешь ввиду, что я её покормил 50Кб файлом, или она ещё до этого растолстела :?: :D
  • maximYCH wrote:
    Птичка слегка растолстела.
    Ахаха, убила фраза, хз почему.
    Ты имеешь ввиду, что я её покормил 50Кб файлом, или она ещё до этого растолстела :?: :D
    Она уже была на самой грани :wink:
    Если б не твой эксперимент - потом пришлось бы долго искать в чем дело.

    Кстати, а нафиг тебе этот экран сдался - он же горит только полсекунды, и столько места занимает?
  • Идеи Максима отличаются "красотой и юзабилити" - свистелками и перделками, но иногда побочный эффект бывает позитивным.
  • art_zh, как минимум практикум по укрощению ядра - раз, плюс есть идея с той же целью практикума объединить этапы APM и следующего этапа загрузки (а тогда не факт, что это полсекунды). Кстати, насколько целесообразно такое объединение, если говорить о транке? Я подразумеваю, что можно будет нажать F8, к примеру, на это будет секунда -две отводится, если её не нажали - образ грузится с дефолтными настройками.
    Что значит "столько места занимает"? kerpack сжимает так, что от картинки остается 2,2 Кб. По-моему немного. А если ты про память - сам же говорил, что ядро занимает в памяти 3,5 Мб. 50 Кб - капля в море.
    Mario, нефиг за меня говорить :)
    И вообще, хватит уже всю деятельность по улучшению юзабилти обзывать "свистелками и перделками". Одно дело, если бы добавлялось что-то, что идет в ущерб размеру/скорости, тогда оно реально нафиг не нужно.
    А если повышать юзабилти не в ущерб размеру/скорости - то по-моему тут действует правило "мнение пишущего код важнее", да и я вижу только конструктивные и позитивные начала в такой деятельности.

    Кстати, какой смысл в memmap.inc, если существует const.inc, в котором возможно без описаний, но зато более актуальная карта памяти?

    И ещё. Меня одного коробят вот такие строчки в ядре:

    Code: Select all

    ; // Alver 22.06.2008 // {
    ?
    Если я захочу посмотреть, кто и когда внес этот код - я посмотрю SVN. А в коде то зачем? Лично для меня - ненужное загромождение, отвлекающие от основного. Исключительное ИМХО, которое никого ни к чему не обязывает, исключительно вопрос для прояснения.
  • Можно попробовать рисовать не картинку, а просто линии (то бишь какую-то простую векторную картинку) - тогда мало места занимать будут.
  • Так а оно и сейчас занимает 2 Кб.
    Упакованый kernel.mnt без картинки - 76 Кб
    Упакованый kernel.mnt с картинкой - 78 Кб

    Чем занимается kbd и для чего он нужен?
  • maximYCH, «кто не бережёт копейки, сам рубля не стоит» - перевести на байты, или и так понятно?

    У меня вот чат есть для мобил, и есть куча не моих. Так вот, у них страничка с сообщениями (никаких javascript, так что она грузится каждые 30 секунд) весит аж до 5 килобайт. У меня, при том же количестве сообщений, около килобайта. Что я такого большого выкинул? Ничего. Каждое изменение, совершаемое для минимизации сокращало код максимум на 10 байт, а чаще на 1-5. Юзабилити при этом, по мнению пользователей, вне конкуренции среди вэб-чатов. А теперь сравни
    5120 байт и 10. Потом сравни 5120 и 1024. Ну и, наконец, 72кб и 74. Внося юзабилити, можно до определённого предела не жертвовать размером и скоростью вовсе.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • maximYCH wrote:Кстати, какой смысл в memmap.inc, если существует const.inc, в котором возможно без описаний, но зато более актуальная карта памяти?

    И ещё. Меня одного коробят вот такие строчки в ядре:

    Code: Select all

    ; // Alver 22.06.2008 // {
    ?
    Если я захочу посмотреть, кто и когда внес этот код - я посмотрю SVN. А в коде то зачем? Лично для меня - ненужное загромождение, отвлекающие от основного. Исключительное ИМХО, которое никого ни к чему не обязывает, исключительно вопрос для прояснения.
    Хорошие вопросы, растёшь!

    const.inc определяет только часть статических адресов ядра. И кроме них - множество других констант, не имеющих никакого отношения к адресной карте.
    mmemmap.inc - это робкая попытка документирования адресного пространства. Не очень удачная, и не всегда когеррентная реальным адресам.

    Насчет старых авторских комментов - меня тоже они иногда раздражают. Это просто строительные леса, которые автор забыл убрать и заменить разумными комментариями после завершения работ.
    Многие из них можно спокойно почистить, но не все. Иногда это - единственный ключ к пониманию некоторых зубодробительных кусков чужого кода.
    плюс есть идея с той же целью практикума объединить этапы APM и следующего этапа загрузки (а тогда не факт, что это полсекунды). Кстати, насколько целесообразно такое объединение, если говорить о транке?
    APM - мёртв, а ACPI еще нет... :twisted:
    (да простит меня БГ за каламбур)

    Весь APM-сервис скоро придется выскабливать из ядра.
    В А-версии я его заменяю прямым PM-кодом. В основном транке - ждем ACPI.
  • art_zh wrote:const.inc определяет только часть статических адресов ядра
    Мне вот непонятно, а почему в ядре должны быть какие-то статические адреса? Когда речь идёт о стандартном древнем оборудовании, там дело ясное: адреса жёстко заданы разработчиками железа, и с этим ничего не поделаешь. Но собственно системные-то вещи, исходя из здравого смысла, могут размещаться в произвольном месте памяти. Более того, чтобы облегчить модификацию и расширение системы, целесообразнее как раз ничего не фиксировать, а оставить определение окончательных адресов на откуп компоновщику и загрузчику. Тогда, например, разрастание секции глобальных данных ядра не приведёт к необходимости ручками править положение стека ядра, динамической памяти и т.п. -- всё автоматически передвинет компоновщик. Или я во что-то не врубаюсь?
  • Не врубаешься.
    1. Вещи, очевидные для ЯВУшников, не являются таковыми для ассемблерщиков.
    2. Давно было высказано предположение, что Вилле собирался использовать статические адреса для взаимодействия с загружаемыми драйверами.
  • Who is online

    Users browsing this forum: No registered users and 9 guests