Этот вопрос задавали многие,но получали на него отридцательный ответ.
А все дело в том,что скорость передачи через IPC очень мала.И подходит только для передачи параметров программе(например пути к файлу).
Менеджер DLL в MeOS
а зачем поддержка библиотек в ядре?
в FASM можно скомпилировать:
грузим её в память с помощью менеджера памяти, получаем смещение каждой функции и делаем вызовы
в FASM можно скомпилировать:
Code: Select all
use32
ord 0x0
dd 3 ;- число функций
dd func1
dd func2
dd func3
func1:
...
ret
func2:
...
ret
func3:
...
ret
>грузим её в память с помощью менеджера памяти, получаем смещение каждой функции и делаем вызовы.
Вот как раз на этом пункте все дело и встало.Нужно совершенствовать менеджер памяти для этого дела.А в менеджере памяти разбирается только сам автор - Халявин Андрей.
Вот как раз на этом пункте все дело и встало.Нужно совершенствовать менеджер памяти для этого дела.А в менеджере памяти разбирается только сам автор - Халявин Андрей.
Да не на этом всё стало. Как раз-таки в менеджер памяти добавить несложно.
1. Грузить надо по какому-то адресу, и вряд ли это адрес 0, как для приложений. А тогда придётся либо требовать загрузку по фиксированному адресу (что не есть хорошо), либо писать полностью позиционно-независимые DLL (и по коду, что несложно, и по данным, что гораздо хуже), либо мучиться с перемещаемыми элементами (relocations), что потребует как мимнмум разработки формата DLL. А ведь нужно ещё учитывать, что в разные процессы DLL может загружаться по разным адресам...
2. Грузить DLL надо из каких-то файлов. А где эти файлы хранить? Кроме как на рамдиске - нехорошо, поскольку FAT32-винта может и не быть (дискета - не вариант), а на рамдиске и так куча файлов (папки не поддерживаются).
3. Помимо явной загрузки DLL бывает ещё неявная - кодом загрузки программ, которая в большинстве случаев удобнее: в exe-шник помещается информация о том, что импортируются такие-то функции таких-то библиотек, в результате к началу исполнения программы без каких-либо системных вызовов адреса всех функций уже "на месте". А для этого нужно уже развивать формат exe-шников.
1. Грузить надо по какому-то адресу, и вряд ли это адрес 0, как для приложений. А тогда придётся либо требовать загрузку по фиксированному адресу (что не есть хорошо), либо писать полностью позиционно-независимые DLL (и по коду, что несложно, и по данным, что гораздо хуже), либо мучиться с перемещаемыми элементами (relocations), что потребует как мимнмум разработки формата DLL. А ведь нужно ещё учитывать, что в разные процессы DLL может загружаться по разным адресам...
2. Грузить DLL надо из каких-то файлов. А где эти файлы хранить? Кроме как на рамдиске - нехорошо, поскольку FAT32-винта может и не быть (дискета - не вариант), а на рамдиске и так куча файлов (папки не поддерживаются).
3. Помимо явной загрузки DLL бывает ещё неявная - кодом загрузки программ, которая в большинстве случаев удобнее: в exe-шник помещается информация о том, что импортируются такие-то функции таких-то библиотек, в результате к началу исполнения программы без каких-либо системных вызовов адреса всех функций уже "на месте". А для этого нужно уже развивать формат exe-шников.
Ушёл к умным, знающим и культурным людям.
diamond
Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?
Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?
Mario79
Это я перечислил проблемы, пришедшие мне в голову. Предыдущий пост следует считать ещё одной проблемой, а к скобке в конце пункта 2 следует относиться как к исправимому недостатку (хотя если отказываться от рамдиска, это автоматически перестаёт быть недостатком). А писать код, пока не принято решение о дальнейшей судьбе рамдиска, действительно не стоит.
Это я перечислил проблемы, пришедшие мне в голову. Предыдущий пост следует считать ещё одной проблемой, а к скобке в конце пункта 2 следует относиться как к исправимому недостатку (хотя если отказываться от рамдиска, это автоматически перестаёт быть недостатком). А писать код, пока не принято решение о дальнейшей судьбе рамдиска, действительно не стоит.
Ушёл к умным, знающим и культурным людям.
Неееет. Рам диск нужен. Я хотел в дальнейшем предложить его использовать как некое подобие реестра и для хранения стандартных элементов системы (конфиги, установленные драйвера, необходимые для системы проги, стандартные иконки), но для этого, как раз нехватает поддержки папок.Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?
А в связи с повсеместной мобилизацией осей, рам диск используется почти везде. В любом случае, в дальнейшем, может возникнуть необходимость в поддержке рам диска, особенно если комп без винта, а загрузка и работа системы выполняется через флэш'ку.
Выношу вердикт - RAM-диску быть!
Я тоже за RD, но дело не в этом. Можно сделать реестр библиотек, где указывается местонахождение билиотеки.
Для библиотеки должна быть точка входа, где в качестве параметра имеется ссылка на адрес для данных. В точке входа выделяется память, и идёт работа через смещения, а для каждой процедуры указывать этот адрес.
Для библиотеки должна быть точка входа, где в качестве параметра имеется ссылка на адрес для данных. В точке входа выделяется память, и идёт работа через смещения, а для каждой процедуры указывать этот адрес.
Я начал переписывать менеджер памяти. Пробный образец уже работает. Можно будет выделять память в адресном пр-ве
ядра и грузить туда драйверы и библиотеки. Для библиотек можно использовать COFF формат - он стандартен, хорошо описан и
главное поддерживается FASM. Там есть таблицы релокаций, так что программы можно будет грузить по любому адресу.
ядра и грузить туда драйверы и библиотеки. Для библиотек можно использовать COFF формат - он стандартен, хорошо описан и
главное поддерживается FASM. Там есть таблицы релокаций, так что программы можно будет грузить по любому адресу.
Можно Ярековский ld-dll вспомнить и довести до ума
Serge
Переписывать? А как же старый менеджер памяти? Может быть, лучше расширить его функциональность?
Или у него есть принципиальные неустранимые недостатки?
Хотелось бы побольше узнать о том, что, как и почему планируется сделать.
Переписывать? А как же старый менеджер памяти? Может быть, лучше расширить его функциональность?
Или у него есть принципиальные неустранимые недостатки?
Хотелось бы побольше узнать о том, что, как и почему планируется сделать.
Иван Поддубный
Кажется ты писал, что кроме автора никто не знает как он работает. Я честно пытался разобраться в его работе и кое-что понял. Например функция выделения физической выделяет всего 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 мегабайт адресов зарезервировано под ядро. Надо окончательно определится с размероми памяти ядра и памяти приложений.
Кажется ты писал, что кроме автора никто не знает как он работает. Я честно пытался разобраться в его работе и кое-что понял. Например функция выделения физической выделяет всего 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 мегабайт адресов зарезервировано под ядро. Надо окончательно определится с размероми памяти ядра и памяти приложений.
Serge
68ая функция предназначена для выделения непрерывного блока физической памяти. Это не malloc/free!!! Непрерывная физическая память нужна для работы с железом через DMA.
Да, выделяется не больше 24 блоков. Но пока этого достаточно.
Ещё раз подчеркну: менеджер физической памяти и менеджер памяти - это совершенно различные вещи! Не надо их путать.
Что касается менеджера памяти, то я сейчас пытаюсь в нём разобраться. Хотелось бы ввести для приложений malloc и free. Но для этого придется убрать функцию 64...
68ая функция предназначена для выделения непрерывного блока физической памяти. Это не malloc/free!!! Непрерывная физическая память нужна для работы с железом через DMA.
Да, выделяется не больше 24 блоков. Но пока этого достаточно.
Ещё раз подчеркну: менеджер физической памяти и менеджер памяти - это совершенно различные вещи! Не надо их путать.
Что касается менеджера памяти, то я сейчас пытаюсь в нём разобраться. Хотелось бы ввести для приложений malloc и free. Но для этого придется убрать функцию 64...
Ядро отображается дважды из-за того, что планировалось перенести ядро в верхние адреса и перейти от сегментно-страничной модели памяти к чисто страничной.
Селектор gs, по-моему, никому не мешает.
Распределение памяти в КолибриОС:
Селектор gs, по-моему, никому не мешает.
Распределение памяти в КолибриОС:
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'ов в исходниках быть не должно - они порождают слишком много проблем.
На счет нормального alloc'a и free - нужно реализовывать структуру почти уровновешенного дерева, иначе поиск пустого блока в адресном пространстве может стать слишком долгим. Конечно простой список для начала сойдет.
PS Serg На сколько я понимаю тебе придется разбираться с файлами mem.inc и newprocess.inc, а файл memmanager.inc тебе будет нужен только в качестве справки по доступным функциям менеджера памяти. Как автору большей части кода в этих файлах можешь посылать вопросы в приват или по e-mail (он в исходниках есть).
PSPS Для удобства добавления изменений в ядро следует внимательно следить за выравниванием - оно не должно сбиваться по всему файлу (такое бывает, когда используются редакторы с разными размерами tab size). Вообще tab'ов в исходниках быть не должно - они порождают слишком много проблем.
Who is online
Users browsing this forum: No registered users and 32 guests