Board.KolibriOS.org

Начало темы здесь http://meos.sysbin.com/viewtopic.php?p=8772

Чтобы было понятно о чём идет речь.

В плоской модели памяти базовые адреса всех сегментов равны нулю,пределы 4Гб-1 а защита ядра от программ осуществляется при помощи таблиц страниц. При такой схеме если программа передаёт ядру указатель на свои данные, например буфер для чтения файла, ядру нет необходимости переводить его в своё адресное пространство прибавлением std_application_base_address как это происходит сейчас.

Такая организация памяти очень проста и стала общепринятой. В новой архитектуре AMD64 (Intel® EM64T) базовые адреса сегментов уже установлены в ноль а пределы игнорируются, то есть плоская модель памяти лежит в основе всей архитектуры.

МеОС не было страничной памяти поэтому у каждой программы были свои дескрипторы сегментов где был установлен базовый адрес приложения в памяти, а виртуальный адрес равнялся нулю.
(Для тех кто запутался. В команде mov eax, [0x1234567] 0x1234567 виртуальный адрес. При выполнении комады к нему прибавляется базовый адрес сегмента и образуется линейный адрес. Если работает страничное преобразование то через таблицы страниц этот адрес преобразуется в физический адрес данных в памяти компьютера. Если привыкнуть то ничего сложного ).

Когда Андрей Халявин сделал менеджер памяти у всех приложений стали общие дескрипторы сегментов, а их базовый адрес был установлен в 0х1000000. Так появился std_application_base_address. Каждое приложение получило своё адресное пространство защищённое таблицами страниц а память ядра вместе в LFB составила 16 Мб.
Я изменил это распределение памяти. Сейчас ядро занимает адреса 0-0х5FFFFFFF таблицы страниц 0x60000000-0x603FFFFF, зачение std_application_base_address равно 0х60400000 и приложения оказались сверху ограничены LFB, который отображается непосредственно на адреса видеопамяти. В общем это не самая удачная организация памяти но предполагалось что ядру будет доступна вся имеющаяся видеопамять а приложения смогут обращаться к ней напрямую без селектора gs. Позже оказалость что на старых видеокартах VESA не показывает правильного размера видеопамяти, что приводило к зависаниям, поэтому сейчас размер LFB устанавливается в 8 Мб.

Что предлагается.
Всё адресное пространство будет поделено на две равные части. Базовые адреса всех сегментов будут установлены в 0 а пределы в в 4Гб-1. Программы будут компилироваться с org 0x80000000 и занимать адреса 0х80000000-0хFFFFFFFF, так что макимальный размер программы и данных составит 2Гб.

Ядро и его данные займут адреса 0-0х7FFFFFFF, из них таблицы страниц 0x7FC00000 - 0х7FFFFFFF, LFB 0x7F400000-0x7FBFFFFF. Память ядра будет защищена от программ битами в таблицах страниц так что программы не смогут его переписать.

Часть изменений можно сделать сразу, для приложений они будут совершенно прозрачны. Окончательно всё можно будет закончить через несколько месяцев, а за это время найти и собрать на SVN исходники всех программ.

Serge
В принципе я за первый вариант. А как с защитой - все останется как было: 0 кольцо ядро, 3 кольцо приложения?

2 Гигабайта это хорошо). Но как решить проблему есть нужно будет под данные скажем больше 2 Гб ?
Я уже высказался что я за изменения в ядре!

Я тоже согласен с плоской моделью памяти.

Ещё одно пояснение.

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

Mario79
Да у ядра 0 и 3 у приложений. Но принцип защиты немного изменится. В таблицах страниц есть бит привилегий U/S (user/suprevisor). Когда он сброшен PL_3 программа не сможет получить доступ к странице, произойдёт страничное нарушение. Таким образом получается двухуровневая система привилегий когда вся защита памяти осуществляется только таблицами страниц. Эти биты уже используются, но сейчас у программ нет возможности "залезть" в ядро.

<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 должна быть там. Или не так?