Новая модель ядра

Kernel architecture questions
  • Поддерживаю.
  • Мне понравилось.
    Поддерживаю!
  • За поддержку спасибо.

    Предлагаю обсудить распределение памяти внутри ядра.
    Сейчас карта памяти содержит много дыр. Можно часть переменных из диапазона 0x0000 - 0xFFFF объявить в коде ядра через uglobal и постепенно отказаться от размещения переменных по непосредственным адресам. Всем найденым переменным я дал имена в верхнем регистре. Эти имена предварительные, их можно обсудить и изменить. Сейчас код выглядит так

    Code: Select all

    const.inc
    
    MOUSE_X             equ 0x0100FB0A
    MOUSE_Y             equ 0x0100FB0C
    
    m_ps2.inc
    
    add     AX,[MOUSE_X]    ;[XCoordinate]
    cmp     AX,0
    jge     @@M1
    mov     AX,0
    
    Теперь по распеределению памяти.
    В диапазоне 0x0000-0xFFFF можно сохранить таблицу прерываний реального режима и область данных БИОС Выше поместить IDT и GDT. IDT занимает максимум 2 кб для GDT можно зарезервировать место на 1024 селекторов оставшееся место использовать для загрузки/перезагрузки ядра. Для кода ядра можно зарезервировать 256-384 кб и разместить в диапазоне 0x40000 - 0x9FFFF оставшуюся память использовать для работы со старыми ДМА.
    Все остальные данные из первого мб памяти перенести выше 1 мб. LFB будет отображаться непосредственно на адреса видеопамяти поэтому все данные с адресов 0xC00000-0xFFFFFF можно сдвинуть вниз на адреса 0x800000-0xBFFFFF.
    После перехода к страничной адресации эти физические адреса памяти будут отображены на диапазон линейных 0x80400000 и выше, а приложения будут использовать адреса 0x0000 - 0x7FFFFFFF. Базовые адреса всех дескрипторов будут выставлены в 0x0000 - получится "простая плоская модель памяти".
  • Serge
    Я так понимаю, что не только приложения, но и само ядро будет обращаться к памяти через менеджер памяти?
    Перенесение всех переменных и областей будет титаническим трудом.
    для GDT можно зарезервировать место на 1024 селекторов
    Для оконного стека придется зарезервировать тоже 1024 входа.
  • Mario79
    Я так понимаю, что не только приложения, но и само ядро будет обращаться к памяти через менеджер памяти?
    Если речь идет о выделении и возвращении памяти, то оно должно происходить через менеджер памяти это нормально для любой ОС. Резервировать память и располагать ее по фиксированным адресам тупиковый путь. На определение всех переменных я потратил 11 дней и большая часть времени ушла на отлов всяких [0xFE04] которым вообще не место по фиксированным адресам. Что касается стека окон, то данные разбросаны в разных местах и очень завязаны на максимальное количество окон и PID. Переделка оконной системы это отдельный большой вопрос.
  • По GUI есть некоторые наработки, но без DLL для пользовательских процессов они ничего не стоят.
    Пока стоит оставить его, как есть. Главное, чтобы "перенесённое" ядро правильно работало.
    Когда появится постраничное выделение/освобождение памяти для программ, можно будет полностью выкинуть старый GUI.

    Что касается резервирования, то соглашусь с тем, чтобы всю память выше 1 или 2 Мб выделять динамически. второй мегабайт можно отдать под DMA и т.п. Можно и не весь второй мегабайт...

    Для простоты можно весь диапазон [0; 2] Мб отобразить однозначно на 0x80000000, а таблицы страниц - на 0x80200000. Или наоборот.

    Кстати, в новых FASM 1.65.20+ какие-то изменения, связанные с адресами. Я пока не разобрался, но стоит посмотреть.
    http://board.flatassembler.net/topic.php?t=5162
  • Сейчас используется 512 байт для FDC DMA и 64 кб для SoundBlaster. Можно оставить под ISA DMA 256 кб и разместить их в первом мегабайте, не думаю что понадобится больше. PCI DMA могут работать с памятью по любому адресу и для них память можно выделять динамически. Память под ядро и LFB можно выделять большими страницами по 4 Мб это повышает быстродействие но такие страницы должны быть выравнены на 4 Мб. Так что получается два варианта или буферы DMA и ядро делят вместе первые 4 Мб и отображаются одной большой страницей, или ядро грузится начиная с 4 Мб а часть первых 4 Мб резервируется под DMA а остальная память будет выделяться 4 Кб страницами, но при таком варианте страничная память будет фрагментирована ужи при загрузке.
  • А для буферов AC97 разве не требуется память DMA? Проблема не в том, чтобы выделить N страниц, а в том, чтобы выделить N последовательных страниц.

    Страницы 4 Мб вроде бы стали доступны только начиная с какого-то Пентиума? Как быть с обратной совместимостью?
  • Большие страницы появились в Пентиум и АМД К5, глобальные в Пентиум Про. Проблем с совместимостью не будет. Можно написать разные версии кода в зависимости от возможностей процессора. Что касается выделения последовательных страниц для буферов ДМА то это тоже не проблема. Можно написать код для выделения страниц блоками разной длины и с разным выравниванием.
  • Serge
    Можно написать код для выделения страниц блоками разной длины и с разным выравниванием.
    Вот это было бы весьма кстати и не только для DMA.
    Например, буфер под валпапер должен располагаться в непрерывной области и занимать ровно столько, сколько нужно для картинки. Так мы сможем не использовать его совсем на машинах с малым количеством ОЗУ и рациональней использовать выделенную под это дело память вообще. Например, для закраски фона однотонным цветом буфер не нужен вообще.
  • Надо еще подумать об использовании видеопамяти на картах где больше 4 Мб. Сейчас она пропадает зря.
  • Только надо помнить,что чтение из видеопамяти происходит на порядок медленнее,чем запись.Но это все-же быстреее,чем
    эмулировать оперативку при помощи жесткого диска.
  • А это идея - выбрасывать редкоиспользуемые страницы в видеопамять, когда свободная оперативка заканчивается.
    Она уже где-нибудь реализована?
  • Serge wrote:Всем
    Я заменил все непосредственные адреса на символьные и переместил ядро. Пока грузится по адресу 0х01010000, адреса 0х0 - 0x00FFFFFF используются для обнаружения ошибок со старыми адресами.
    Предлагаю использовать адреса 0x0 - 0x7FFFFFFF для приложений, 0x80000000-0x803FFFFF для таблиц страниц 0x80400000 и выше для системы. LFB можно отображать на родные адреса видеокарты.
    Почему бы прямо не написать - давайте использовать модель памяти Windows NT? ;)
  • Who is online

    Users browsing this forum: No registered users and 7 guests