Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Oct 27, 2020 10:51 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 13 4 5 6 715 Next
Author Message
 Post subject:
PostPosted: Wed Apr 19, 2006 6:16 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Практически будет три менеджера памяти.
Менеджер страничной памяти.
Его работа должна быть совершенно прозрачной для программ и большинства функций системы.
Менеджер кучи для ядра. Это может быть любая вариация malloc выделяющая память блоками, кратными странице, и выравненными на размер страницы.
Менеджер кучи для приложений.
Эта функция будет выделять память страничными блоками но по адресам, доступным приложению. Просто malloc портирую на основе кода написанного Doug Lea (используется GNU libc, описание на http://gee.cs.oswego.edu/dl/html/malloc.html).
Что касается 64 функции то она не сильно мешает. Можно резервировать для старых программ 4 мегабайта адресов от начала приложения и пусть ф.64 с ними работает. БОльшие блоки памяти будут получаться через вызов user_alloc и освобождаться user_free. Их описание будет сильно похоже на MS Win VirtualAlloc. Что касается выделения памяти для DMA, то здесь нет никаких проблем, можно определить те области физической памяти, которые используются устройствами и при необходимости отображать в адресное пространство задачи как это происходит с LFB. Селектор gs никому не мешает и трогать его я не собираюсь. Просто можно вызовом user_alloc зарезервировать в адресном пространстве программы буфер, отобразить туда LFB и работать с ним обычным образом. А ещё большинство видеокарт имеют больше 4 мБ памяти и эти мегабайты совсем не используются. Речь шла об этом.


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 8:06 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Грузить библиотеки в адресное пространство ядра?! Чтобы код DLL-ки исполнялся в 0-кольце?! И маленький глюк библиотеки рушил систему нафиг?! (Я уж молчу про огромную дыру в безопасности в этом случае). И для разных процессов одна и та же DLL-ка, как правило, использует разные данные.
Ты предлагаешь при запуске выделять программе столько памяти, сколько ей надо, а не сколько указано в заголовке. Эту фразу я могу истолковать только одним способом - будет изначально выделяться память под размер файла и в дальнейшем, по мере обращения к существующим, но не выделенным страницам, обработчик #PF будет выделять новую физическую память. А это - сильные тормоза.
Проблема с malloc/free следующая. В принципе функции 64 самой по себе достаточно для организации менеджера памяти 3-кольца в самой программе. Дело в том, что создавать malloc/free как системные вызовы неэффективно - при выделении малых объёмов памяти каждый раз выходить в 0-кольцо и возвращаться - очень медленно. В Windows и Linux это реализовано в DLL (Windows, функции HeapAlloc/HeapReAlloc/HeapFree) / shared libraries (Linux, malloc/realloc/free). Ну а под DOS/Windows каждый компилятор ЯВУ считает своим долгом вставить собственную реализацию malloc/free прямо в exe-шник (причём не базирующуюся на Heap*, а выполняющую кучу теоретически эффективных действий).
И кстати, можно особо не ссылаться на то, что FASM поддерживает COFF - я хорошо разбираюсь в исходниках FASM'а (а также в исходниках ядра - практически всех, кроме работы с сетью и железом, но включая вышеупомянутый менеджер памяти) и без проблем могу добавить поддержку нового формата - был бы формат...

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 11:09 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
1. Пока речь идет только о загрузке драйверов и то только на стадии прожектов. Сейчас ситуация с драйверами вообще никакая. Я пытаюсь это изменить.
2. Ты совершенно точно уловил принцип: выделять память в обработчике #PF. И это не сильные тормоза, мы же не грузим страницы с диска. Зато это решает все проблемы с прожорливыми приложениями. Исключение обрабатывается без преключения задач а выделение страницы происходит быстро. На худой случай, если программа так торопится получить всю память сразу можно использовать в самом начале mov eax, [4096], mov eax, [8192] и т.д. хотя я считаю это плохой идеей.
3. Я не собираюсь создавать malloc/free как системные функции. это будет простой inc файл с необходимым кодом.
в начале программы надо вызвать init_malloc, которая создаст кучу и сделает всю черновую работу. Например jpeglib из jpegview использует свою версию malloc. Я хочу сделать версию malloc доступную для всех. Думаю многие нуждаются в этом. Если у кого то уже есть готовые решения - очень хорошо.
4. По поводу COFF.
Это один из вариантов. Формат хорошо описан и он подходит для этих целей. Если есть другие подходящие стандартные форматы - можно использовать их, это лучше, чем изобретать свой уникальный формат.
Наконец можно сделать разные версии загрузчиков.
Последнее.
Твой отладчик здорово помог мне разобраться с загрузкой сжатых программ. Увы функции, которые он использовал пока не доделаны. Если не сложно, пожалуйста напиши мне на infinity_sound<собака>mail.ru какие системные функции использует отладчик и какие функции от менеджера памяти ему могут понадобиться. Кстати, отладчик кандидат номер 1 на загрузку в ядро - это обещает большие возможности.

Для всех
Каким должен быть размер адресного пространства приложений? Сколько резервироватьь на нужды ядра?


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 7:00 am 
Serge
Чем тебя не устраивает текущая карта памяти? В ней для приложений отведено 2Гb-256Mb. Для ядра - 1Гb-16Mb ( общий размер оперативки должен быть так же меньше данного числа).
memtest.7z - как раз реализация malloc/free/realloc для приложений в виде .inc файла (основанная только на 64 функции).


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 11:42 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge
Отправил. Впрочем, описание 69-й функции скоро войдёт в документацию, которую я делаю.
Сам отладчик mtdbg работает только через 69-ю функцию (даже 64-ю пока не использует), а вот в ядре код обработки системных функций использует read/write_process_memory и сообщения отладки, реализация которых аналогична IPC (функция debugger_notify из debug.inc).

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 12:26 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond

Можно в обработчике #PF выделять память не по одной странице а блоками по 4, 8 и т.д.
Например если в системе осталось мало памяти можно использовать "скупой" вариант и выделять по одной странице, если много выделять несколько страниц. При загрузке программы выделять память только под загрузку файла, а дальше уже в зависимости от доступной физической памяти


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 12:36 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
halyavin

Я думаю что память ядра лучше держать одним блоком. например 0-256 мБ ядро 256мБ и выше приложения.
Можно сразу зарезервировать под ядро 1 гБ и отдать все остальное место приложениям. Считаю, что не стоит разбивать адресное пространство ядра на верхнюю и нижнюю часть а в середине держать приложение. Это усложняет работу с таблицами страниц.


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 12:54 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
halyavin

Как я понимаю 64 функция использовалась когда страничной памяти не было и нужно было изменять пределы сегменто кода и данных. Со страничной памятью в этом нет необходимости пределы сразу устанавливаются на максимальное значение и 64 ф. просто прибавляет и отрезает память от конца программы.
Теперь вопрос. Графический редактор создает 4мб буфер, потом еще два буфера по 2 мБ и решает что первый буфер ему не нужен.
Что сделает 64 функция?


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 1:17 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
64 ничего сама не делает. В твоём примере она поможет, только если программа переместит оставшиеся 2 блока вниз.


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 6:04 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Вот и я о том же.
А почему не удалось переместить ядро по адресам 0хС0000000+? Идея неплохая, Может стоит довести ее до завершения?


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 6:23 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Serge,в моем графическом редакторе память выделяется так.

При запуске программы резервируется 100 килобайт памяти(под саму программу).Потом выделяется 4 мегабайта под экранный буфер при помощи ф.64.
При открытии графического файла программа смотрит,не помещается ли файл в 4-х мегабайтовую область.Если не помещается,то выделяется дополнительная память равная (размер_графического_файла - 4Мб).
Потом программа смотрит какого размера картинка.Резервируется 64 ф. дополнительная память
(Picture_SizeX*Picture_SizeY*3)*2.
В первом буфере храниться сама картинка,а во втором её копия,для того,чтобы реализовать возможность
'ОТМЕНА ПОСЛЕДНЕГО ДЕЙСТВИЯ'

Надеюсь изменение менеджера памяти не сильно скажется на работе 64 функции.А то не хочется переписывать код графического редактора(я и так его с нуля переписывал в феврале ).


Top
   
 Post subject:
PostPosted: Thu Apr 20, 2006 7:48 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Никаких изменений в работе 64ф. не будет. Будет два варианта или ф 64 или user_alloc, выделяющая блок и возвращающая указатель. Использовать их вместе не получится.
Я хочу максимально сохранить возможности существующих функций, добавив несколько новых.


Top
   
 Post subject:
PostPosted: Fri Apr 21, 2006 6:59 pm 
Serge
Переместить все ядро по адресам 0xC0000000+ не удалось потому, что нужно модифицировать кучу кода по всему ядру. Некоторое упрощение произойдет если поставить org 0xC0000000. Но нужно решить в какое именно место его поставить (например нельзя этого делать до инициализации таблиц страниц в менеджере памяти). Здесь главная проблема - объем работы. Можно создать на нашем subversion-сервере отдельную ветку и постепенно проводить эти изменения. Возьмешься за реализацию этого проекта?

Если удастся сделать нормальный менеджер адресного пространства ядра, то можно будет и не отображать динамическую память на адреса 0xC01000000+ (оно нужно в основном для того, чтобы выделять одну страницу без необходимости модификаций таблиц страниц).


Top
   
 Post subject:
PostPosted: Fri Apr 21, 2006 7:22 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Я готов взяться за эту работу и кое что уже начал делать. Но мне нужен доступ к вашему серверу версий и объясните как с ним работать, у меня есть небольшой опыт работы с CVS.
И ещё надо отказаться от использования абсолютных адресов в численном виде. Например mov eax, [0x3000+ebx+0x10]
заменять на

чего_то_там equ 0x3000
mov eax, [чего_то_там+ebx+0x10]

Создать файл для всех таких глобальных переменныых и дать им имена.
Это сильно упростит все возможные модификации в дальнейшем и снизит риск ошибок.

И надо окончательно определиться с распределением адресного пр-ва.

Можно зарезервировать нижние 2 гБ адресов для приложений и верхние два для ядра системы. И зарезервировать часть физической памяти в диапазоне 0 - 0х00FF FFFF для старых устройств ДМА.


Top
   
 Post subject:
PostPosted: Wed May 10, 2006 11:17 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
Посидев как-то на канале #meos и пообщавщись с mike.dld решил попробовать реализовать какое-то подобие длл. Уже есть небольшие наброски. Конечно на менеджер длл то что я сделал совсем не тянет,но это единственная тема про длл на форуме (...а может я полохо искал).
То что я сделал буду называть пока недодлл (с лёгкой руки Поддубного...). Эта недодлл уже может грузить библиотеки простого формата (небольшой заголовок,пару таблиц и код),использовать функции библиотек. Библиотеки тоже в совю очередь могут грузить библиотеки и использовать их фунции. Пока не разобрался с релоками и не знаю как проводить инициализацию библиотек (нужен менеджер памяти,пока нашёл мп от halyavin и от mike.dld... ). Если кто заинтересовался могу выслать код.... и жду конструктивной критики


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 13 4 5 6 715 Next

All times are UTC+03:00


Who is online

Users browsing this forum: Google [Bot] and 1 guest


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