Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт ноя 23, 2017 10:36 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 69 сообщений ]  На страницу 1 2 3 4 5 След.

Нужна ли Колибри плоская модель памяти
Да. Это хорошая идея 92%  92%  [ 36 ]
Нет. Нам необходима совместимость с программами для МеОС 3%  3%  [ 1 ]
Давайте подождём пару лет 5%  5%  [ 2 ]
Всего голосов: 39
Автор Сообщение
 Заголовок сообщения: Плоская модель памяти
СообщениеДобавлено: Чт янв 25, 2007 2:34 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Начало темы здесь 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 исходники всех программ.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 2:57 pm 
Serge
В принципе я за первый вариант. А как с защитой - все останется как было: 0 кольцо ядро, 3 кольцо приложения?


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 3:13 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
2 Гигабайта это хорошо). Но как решить проблему есть нужно будет под данные скажем больше 2 Гб ?
Я уже высказался что я за изменения в ядре!


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 3:19 pm 
Не в сети

Зарегистрирован: Ср июл 05, 2006 9:00 am
Сообщения: 81
Я тоже согласен с плоской моделью памяти.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 3:24 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Ещё одно пояснение.

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

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


Последний раз редактировалось Serge Чт янв 25, 2007 6:24 pm, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 3:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
<Lrz>
Можно конечно изменить соотношение между приложением и ядром, но главное здесь не ошибиться.
Есть другое решение этой проблемы при помощи таблиц страниц. Данные собираются в большие блоки, которые отображаются на одинаковые адреса но одновременно в память приложения отображается только один блок данных. Это похоже на древние оверлеи, только работает немного по-другому. Правда я не знаю когда в Колибри появятся приложения которым не хватит 2 Гб. Может когда idSoftware опубликует исходники Doom3 и его можно будет портировать :)
Кстати сейчас максимальный размер приложения не может превышать 1.5 Гб


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 3:55 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
Я с течением времени перепишу XML parser. Если скажем ему нужно будет обработать большие объемы информации и для данных может потребоваться более 2 Гиг адресного пространства. Не стоит забывать о будующем.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 4:30 pm 
Serge
Цитата:
Может когда idSoftware опубликует исходники Doom3 и его можно будет портировать

Че уж мелочиться - сразу надеемся на халву вторую. ;-)

<Lrz>
Проблемы нужно решать по мере поступления, когда будет реальная необходимость.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 4:46 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
<Lrz>
Один раз я открыл в Visual Studio 25Mb XML-сэйв. Она его жевала минут двадцать и зависла. Вообще где мало 2 Гб может и 8 не хватить а в PC доступно "всего" 3.5


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт янв 25, 2007 5:15 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
Ok, если появиться проблема значит и будем решать )


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 26, 2007 1:34 pm 
Serge
Может все-таки ядро загрузить на 0x80000000+ а приложения на 0x00000000-0x80000000 как в нормальных системах? Только придется много в ядре менять, но вроде многие абсолютные адреса уже сделаны константами.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 26, 2007 3:08 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Один раз я уже пробовал. В принципе это возможно, хотя я теперь не уверен что такая схема лучше. Сразу возникнет проблема с АРМ и перезагрузкой ядра. Надо будет обеспечить доступ к первому Мб ОЗУ, потому что теперь по этим адресам будут программы. Придётся манипулировать таблицами страниц. Большинство переменных я нашёл, но не уверен что все. Возможна ситуация когда долгое время будут всплывать новые ошибки.
У моего предложения есть ещё один плюс. Во многих системах есть защита от NULL указателей когда приложение не может обращаться к памяти по адресу 0х0000. Обычно это делается при помощи таблиц страниц. Теперь эта фича будет и в Колибри.
В общем я не знаю чем ядро по адресу 0х80000000 лучше ядра по адресу 0х0000. Если есть какие-то принципиальные преимущества очень хотел бы узнать.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 27, 2007 7:43 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн мар 20, 2006 10:44 am
Сообщения: 557
ИМХО 0х80000000 лучше, так как там располагаются сервисы BIOS32, таблицы ACPI, точка входа VESA32, etc, и если по верхним адресам разместить приложения, могут возникнуть проблемы с поддержкой этого добра.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 27, 2007 11:55 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Точка входа VESA32 есть не во всех видеокартах и по-моему все давно забили на стандарт. Последняя версия вышла в 98 году и на этом всё закончилось. В ATI 9000+ ещё VESA 2. а карта появилясь через пять лет. Если бы там была графическая акслелерация или установка аппаратного курсора или установка частоты экрана я был бы двумя руками за, а так остался набор давно устаревших функций. Даже размер видеопамяти не все карты определяют.

С сервисами BIOS32 похожая проблема и Колибри их не использует.
Функции APM расположены в нижней памяти иначе они бы не работали потому что ядро не создаёт своих таблиц для адресов выше 0х60000000. А если нужен доступ к верхенй памяти отображает страницы в нижнюю. Так делают драйверы ati2d и unisound для доступа к регистрам контроллеров.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 27, 2007 12:49 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Ghost
БИОС видеокарт ведь в первом мегабайте расположена, значит и точка входа VESA32 должна быть там. Или не так?


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 69 сообщений ]  На страницу 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB