Плоская модель памяти

Kernel architecture questions

POLL Нужна ли Колибри плоская модель памяти

Total votes: 41
Да. Это хорошая идея
93%
38
Нет. Нам необходима совместимость с программами для МеОС
2%
1
Давайте подождём пару лет
5%
2

  • Serge
    В принципе я за первый вариант. А как с защитой - все останется как было: 0 кольцо ядро, 3 кольцо приложения?
  • 2 Гигабайта это хорошо). Но как решить проблему есть нужно будет под данные скажем больше 2 Гб ?
    Я уже высказался что я за изменения в ядре!
  • Я тоже согласен с плоской моделью памяти.
  • Ещё одно пояснение.

    Колибри не сможет запускать программы скомпилированные для МеОС.
    Некоторым программам понадобится переделка, например если там есть подобный код mov [0x1234], eax , надо исправить адрес.
    Если кто-то разрабатывает программы совместимые и с Колибри и с МеОС придётся копилировать две версии. Обычно такие проблемы решаются при помощи условной компиляции, которая есть в FASM.

    Mario79
    Да у ядра 0 и 3 у приложений. Но принцип защиты немного изменится. В таблицах страниц есть бит привилегий U/S (user/suprevisor). Когда он сброшен PL_3 программа не сможет получить доступ к странице, произойдёт страничное нарушение. Таким образом получается двухуровневая система привилегий когда вся защита памяти осуществляется только таблицами страниц. Эти биты уже используются, но сейчас у программ нет возможности "залезть" в ядро.
    Last edited by Serge on Thu Jan 25, 2007 6:24 pm, edited 1 time in total.
  • <Lrz>
    Можно конечно изменить соотношение между приложением и ядром, но главное здесь не ошибиться.
    Есть другое решение этой проблемы при помощи таблиц страниц. Данные собираются в большие блоки, которые отображаются на одинаковые адреса но одновременно в память приложения отображается только один блок данных. Это похоже на древние оверлеи, только работает немного по-другому. Правда я не знаю когда в Колибри появятся приложения которым не хватит 2 Гб. Может когда idSoftware опубликует исходники Doom3 и его можно будет портировать :)
    Кстати сейчас максимальный размер приложения не может превышать 1.5 Гб
  • Я с течением времени перепишу XML parser. Если скажем ему нужно будет обработать большие объемы информации и для данных может потребоваться более 2 Гиг адресного пространства. Не стоит забывать о будующем.
  • Serge
    Может когда idSoftware опубликует исходники Doom3 и его можно будет портировать
    Че уж мелочиться - сразу надеемся на халву вторую. ;-)

    <Lrz>
    Проблемы нужно решать по мере поступления, когда будет реальная необходимость.
  • <Lrz>
    Один раз я открыл в Visual Studio 25Mb XML-сэйв. Она его жевала минут двадцать и зависла. Вообще где мало 2 Гб может и 8 не хватить а в PC доступно "всего" 3.5
  • Ok, если появиться проблема значит и будем решать )
  • Serge
    Может все-таки ядро загрузить на 0x80000000+ а приложения на 0x00000000-0x80000000 как в нормальных системах? Только придется много в ядре менять, но вроде многие абсолютные адреса уже сделаны константами.
  • Один раз я уже пробовал. В принципе это возможно, хотя я теперь не уверен что такая схема лучше. Сразу возникнет проблема с АРМ и перезагрузкой ядра. Надо будет обеспечить доступ к первому Мб ОЗУ, потому что теперь по этим адресам будут программы. Придётся манипулировать таблицами страниц. Большинство переменных я нашёл, но не уверен что все. Возможна ситуация когда долгое время будут всплывать новые ошибки.
    У моего предложения есть ещё один плюс. Во многих системах есть защита от NULL указателей когда приложение не может обращаться к памяти по адресу 0х0000. Обычно это делается при помощи таблиц страниц. Теперь эта фича будет и в Колибри.
    В общем я не знаю чем ядро по адресу 0х80000000 лучше ядра по адресу 0х0000. Если есть какие-то принципиальные преимущества очень хотел бы узнать.
  • ИМХО 0х80000000 лучше, так как там располагаются сервисы BIOS32, таблицы ACPI, точка входа VESA32, etc, и если по верхним адресам разместить приложения, могут возникнуть проблемы с поддержкой этого добра.
  • Точка входа VESA32 есть не во всех видеокартах и по-моему все давно забили на стандарт. Последняя версия вышла в 98 году и на этом всё закончилось. В ATI 9000+ ещё VESA 2. а карта появилясь через пять лет. Если бы там была графическая акслелерация или установка аппаратного курсора или установка частоты экрана я был бы двумя руками за, а так остался набор давно устаревших функций. Даже размер видеопамяти не все карты определяют.

    С сервисами BIOS32 похожая проблема и Колибри их не использует.
    Функции APM расположены в нижней памяти иначе они бы не работали потому что ядро не создаёт своих таблиц для адресов выше 0х60000000. А если нужен доступ к верхенй памяти отображает страницы в нижнюю. Так делают драйверы ati2d и unisound для доступа к регистрам контроллеров.
  • Ghost
    БИОС видеокарт ведь в первом мегабайте расположена, значит и точка входа VESA32 должна быть там. Или не так?
  • Who is online

    Users browsing this forum: Google [Bot] and 8 guests