Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Oct 27, 2020 9:44 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 1 2 3 4 5 615 Next
Author Message
 Post subject:
PostPosted: Mon Apr 10, 2006 6:25 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Этот вопрос задавали многие,но получали на него отридцательный ответ.
А все дело в том,что скорость передачи через IPC очень мала.И подходит только для передачи параметров программе(например пути к файлу).


Top
   
 Post subject:
PostPosted: Sun Apr 16, 2006 10:46 am 
Offline

Joined: Mon Apr 10, 2006 7:22 am
Posts: 76
а зачем поддержка библиотек в ядре?
в FASM можно скомпилировать:
Code:
use32
ord 0x0
dd 3 ;- число функций
dd func1
dd func2
dd func3
func1:
...
ret
func2:
...
ret
func3:
...
ret

грузим её в память с помощью менеджера памяти, получаем смещение каждой функции и делаем вызовы


Top
   
 Post subject:
PostPosted: Sun Apr 16, 2006 11:17 am 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
>грузим её в память с помощью менеджера памяти, получаем смещение каждой функции и делаем вызовы.

Вот как раз на этом пункте все дело и встало.Нужно совершенствовать менеджер памяти для этого дела.А в менеджере памяти разбирается только сам автор - Халявин Андрей.


Top
   
 Post subject:
PostPosted: Mon Apr 17, 2006 5:54 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Да не на этом всё стало. Как раз-таки в менеджер памяти добавить несложно.
1. Грузить надо по какому-то адресу, и вряд ли это адрес 0, как для приложений. А тогда придётся либо требовать загрузку по фиксированному адресу (что не есть хорошо), либо писать полностью позиционно-независимые DLL (и по коду, что несложно, и по данным, что гораздо хуже), либо мучиться с перемещаемыми элементами (relocations), что потребует как мимнмум разработки формата DLL. А ведь нужно ещё учитывать, что в разные процессы DLL может загружаться по разным адресам...
2. Грузить DLL надо из каких-то файлов. А где эти файлы хранить? Кроме как на рамдиске - нехорошо, поскольку FAT32-винта может и не быть (дискета - не вариант), а на рамдиске и так куча файлов (папки не поддерживаются).
3. Помимо явной загрузки DLL бывает ещё неявная - кодом загрузки программ, которая в большинстве случаев удобнее: в exe-шник помещается информация о том, что импортируются такие-то функции таких-то библиотек, в результате к началу исполнения программы без каких-либо системных вызовов адреса всех функций уже "на месте". А для этого нужно уже развивать формат exe-шников.

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


Top
   
 Post subject:
PostPosted: Mon Apr 17, 2006 7:12 pm 
diamond
Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?


Top
   
 Post subject:
PostPosted: Mon Apr 17, 2006 7:19 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Mario79
Это я перечислил проблемы, пришедшие мне в голову. Предыдущий пост следует считать ещё одной проблемой, а к скобке в конце пункта 2 следует относиться как к исправимому недостатку (хотя если отказываться от рамдиска, это автоматически перестаёт быть недостатком). А писать код, пока не принято решение о дальнейшей судьбе рамдиска, действительно не стоит.

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


Top
   
 Post subject:
PostPosted: Mon Apr 17, 2006 11:28 pm 
Offline

Joined: Sat Jan 07, 2006 4:07 am
Posts: 47
Quote:
Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?

Неееет. Рам диск нужен. Я хотел в дальнейшем предложить его использовать как некое подобие реестра и для хранения стандартных элементов системы (конфиги, установленные драйвера, необходимые для системы проги, стандартные иконки), но для этого, как раз нехватает поддержки папок.
А в связи с повсеместной мобилизацией осей, рам диск используется почти везде. В любом случае, в дальнейшем, может возникнуть необходимость в поддержке рам диска, особенно если комп без винта, а загрузка и работа системы выполняется через флэш'ку.
Выношу вердикт - RAM-диску быть!


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 6:31 am 
Offline

Joined: Mon Apr 10, 2006 7:22 am
Posts: 76
Я тоже за RD, но дело не в этом. Можно сделать реестр библиотек, где указывается местонахождение билиотеки.
Для библиотеки должна быть точка входа, где в качестве параметра имеется ссылка на адрес для данных. В точке входа выделяется память, и идёт работа через смещения, а для каждой процедуры указывать этот адрес.


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 12:08 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Я начал переписывать менеджер памяти. Пробный образец уже работает. Можно будет выделять память в адресном пр-ве
ядра и грузить туда драйверы и библиотеки. Для библиотек можно использовать COFF формат - он стандартен, хорошо описан и
главное поддерживается FASM. Там есть таблицы релокаций, так что программы можно будет грузить по любому адресу.


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 12:14 pm 
Offline

Joined: Wed May 25, 2005 8:52 am
Posts: 147
Можно Ярековский ld-dll вспомнить и довести до ума


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 12:50 pm 
Offline

Joined: Fri Nov 12, 2004 3:20 pm
Posts: 90
Serge
Переписывать? А как же старый менеджер памяти? Может быть, лучше расширить его функциональность?
Или у него есть принципиальные неустранимые недостатки?

Хотелось бы побольше узнать о том, что, как и почему планируется сделать.


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 2:58 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Иван Поддубный

Кажется ты писал, что кроме автора никто не знает как он работает. Я честно пытался разобраться в его работе и кое-что понял. Например функция выделения физической выделяет всего 24 блока ( если верить исходникам), блок выделяется не в области приложения, где он нужен больше всего, а где-то в параллельной вселенной и доступ к нему осуществляется через подфункции типа get_buffer и set_buffer функ. 68. Это больше похоже на работу с файлами. Память из диапазона 0х0 - 0х00100 000 (первые 16 мб) также отображаются на адреса 0хС000 0000 (для чего ???). Некоторые программы используют старые флаги mem_size = 0x300000 например 5 килобайтный cmd при загрузке запрашивает 3 мегабайта памяти и получает их!
Я хочу хочу сделать менеджер памяти который будет решать все эти проблемы. Напрмер при загрузке программа будет получать физической памяти ровно столько сколько ей нужно, а не сколько указано в заголовке. При этом сохранится совместимость с нынешними программами, а необходимая физ. память будет выделятся только тогда, когда программа к ней реально обращается. Можно будет отображать видеопамять в адресное пр-во приложения и получать к ней прямой доступ не через селектор gs а обычным путем. Появится возможность эмулировать LFB для старых видеокарт с банками памяти - отпадет необходимость в разных функциях рисования для банков и LFB.
Можно будет использовать глобальные и большие 4 мБ страницы памяти на тех процессорах, где есть
такая возможность

Для выделения памяти в ядре будет функция kernel_alloc, выделяющая и резервирующая память страничными блоками и user_alloc для приложений. Наконец для приложений портирую стандартную библиотечную malloc.
Сейчас ядро с новым менеджером страничной памяти грузится нормально и работают все программы
не использующие read/write_process_memory и IPC. Эти программы вызывают страничные нарушения, зависают и убиваются обычным образом. Больше всего пострадал отладчик, но скоро я напишу все необходимые для его работы функции. Как только будут готовы
kernel_alloc, user_alloc,
read/write_process_memory IPC

сделаю подробное описание всех изменений.

Последнее.
Пока код не устоялся надо определиться с распределением памяти. Например я установил адресное пр-во приложений в 2 гигабайта из них 128 мегабайт адресов зарезервировано под ядро. Надо окончательно определится с размероми памяти ядра и памяти приложений.


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 3:30 pm 
Offline

Joined: Fri Nov 12, 2004 3:20 pm
Posts: 90
Serge
68ая функция предназначена для выделения непрерывного блока физической памяти. Это не malloc/free!!! Непрерывная физическая память нужна для работы с железом через DMA.
Да, выделяется не больше 24 блоков. Но пока этого достаточно.
Ещё раз подчеркну: менеджер физической памяти и менеджер памяти - это совершенно различные вещи! Не надо их путать.

Что касается менеджера памяти, то я сейчас пытаюсь в нём разобраться. Хотелось бы ввести для приложений malloc и free. Но для этого придется убрать функцию 64...


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 3:38 pm 
Offline

Joined: Fri Nov 12, 2004 3:20 pm
Posts: 90
Ядро отображается дважды из-за того, что планировалось перенести ядро в верхние адреса и перейти от сегментно-страничной модели памяти к чисто страничной.
Селектор gs, по-моему, никому не мешает.

Распределение памяти в КолибриОС:
Image


Top
   
 Post subject:
PostPosted: Wed Apr 19, 2006 4:40 pm 
http://shade.msu.ru/~msu-se/memtest.7z - менеджер памяти для приложений. По-видимому это лучшее, чего можно добиться при существующем ядре.
На счет нормального alloc'a и free - нужно реализовывать структуру почти уровновешенного дерева, иначе поиск пустого блока в адресном пространстве может стать слишком долгим. Конечно простой список для начала сойдет.
PS Serg На сколько я понимаю тебе придется разбираться с файлами mem.inc и newprocess.inc, а файл memmanager.inc тебе будет нужен только в качестве справки по доступным функциям менеджера памяти. Как автору большей части кода в этих файлах можешь посылать вопросы в приват или по e-mail (он в исходниках есть).
PSPS Для удобства добавления изменений в ядро следует внимательно следить за выравниванием - оно не должно сбиваться по всему файлу (такое бывает, когда используются редакторы с разными размерами tab size). Вообще tab'ов в исходниках быть не должно - они порождают слишком много проблем.


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

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited