Board.KolibriOS.org

Ещё вопрос.
Подключение строчкой в data32.inc делает kernel.mnt неработоспособным.
Может ли кто-нибудь подсказать, почему?
Файл прилагаю.

kerpack для Windows не делали.

Спасибо, понятно.

лучше data32 покажи

Прикладываю

Интересно, esp ядра устанавливается на 0x3ec00, а .bss (uglobals) заканчивается на 0x413d2. При компиляции с logo стек сразу попадал в .data.
Поздравляю maximYCH, ты обнаружил серьёзный баг в ядре.

Update. Там ещё и gdt под раздачу попадает. Птичка слегка растолстела.

Код работал корректно, насколько я понимаю, в ревизии 803.

Птичка слегка растолстела.

Ахаха, убила фраза, хз почему.
Ты имеешь ввиду, что я её покормил 50Кб файлом, или она ещё до этого растолстела

maximYCH wrote:

Птичка слегка растолстела.

Ахаха, убила фраза, хз почему.
Ты имеешь ввиду, что я её покормил 50Кб файлом, или она ещё до этого растолстела

Она уже была на самой грани
Если б не твой эксперимент - потом пришлось бы долго искать в чем дело.

Кстати, а нафиг тебе этот экран сдался - он же горит только полсекунды, и столько места занимает?

Идеи Максима отличаются "красотой и юзабилити" - свистелками и перделками, но иногда побочный эффект бывает позитивным.

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

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

И ещё. Меня одного коробят вот такие строчки в ядре: ?
Если я захочу посмотреть, кто и когда внес этот код - я посмотрю 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 еще нет...
(да простит меня БГ за каламбур)

Весь APM-сервис скоро придется выскабливать из ядра.
В А-версии я его заменяю прямым PM-кодом. В основном транке - ждем ACPI.

art_zh wrote:const.inc определяет только часть статических адресов ядра

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

Не врубаешься.
1. Вещи, очевидные для ЯВУшников, не являются таковыми для ассемблерщиков.
2. Давно было высказано предположение, что Вилле собирался использовать статические адреса для взаимодействия с загружаемыми драйверами.