Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Apr 23, 2019 5:32 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 69 posts ]  Go to page 1 2 3 4 5 Next

Нужна ли Колибри плоская модель памяти
Да. Это хорошая идея 92%  92%  [ 36 ]
Нет. Нам необходима совместимость с программами для МеОС 3%  3%  [ 1 ]
Давайте подождём пару лет 5%  5%  [ 2 ]
Total votes: 39
Author Message
PostPosted: Thu Jan 25, 2007 2:34 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Начало темы здесь 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 исходники всех программ.


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 2:57 pm 
Serge
В принципе я за первый вариант. А как с защитой - все останется как было: 0 кольцо ядро, 3 кольцо приложения?


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 3:13 pm 
Offline
Kernel Optimizer
User avatar

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


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 3:19 pm 
Offline

Joined: Wed Jul 05, 2006 9:00 am
Posts: 81
Я тоже согласен с плоской моделью памяти.


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 3:24 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Ещё одно пояснение.

Колибри не сможет запускать программы скомпилированные для МеОС.
Некоторым программам понадобится переделка, например если там есть подобный код 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.

Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 3:42 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 3:55 pm 
Offline
Kernel Optimizer
User avatar

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


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 4:30 pm 
Serge
Quote:
Может когда idSoftware опубликует исходники Doom3 и его можно будет портировать

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

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


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 4:46 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Thu Jan 25, 2007 5:15 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Ok, если появиться проблема значит и будем решать )


Top
   
 Post subject:
PostPosted: Fri Jan 26, 2007 1:34 pm 
Serge
Может все-таки ядро загрузить на 0x80000000+ а приложения на 0x00000000-0x80000000 как в нормальных системах? Только придется много в ядре менять, но вроде многие абсолютные адреса уже сделаны константами.


Top
   
 Post subject:
PostPosted: Fri Jan 26, 2007 3:08 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Sat Jan 27, 2007 7:43 am 
Offline
Kernel Developer
User avatar

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


Top
   
 Post subject:
PostPosted: Sat Jan 27, 2007 11:55 am 
Offline
Kernel Developer

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

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


Top
   
 Post subject:
PostPosted: Sat Jan 27, 2007 12:49 pm 
Offline
Kernel Developer

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 69 posts ]  Go to page 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited