Board.KolibriOS.org

Этот вопрос задавали многие,но получали на него отридцательный ответ.
А все дело в том,что скорость передачи через IPC очень мала.И подходит только для передачи параметров программе(например пути к файлу).

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

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

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

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

diamond
Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?

Mario79
Это я перечислил проблемы, пришедшие мне в голову. Предыдущий пост следует считать ещё одной проблемой, а к скобке в конце пункта 2 следует относиться как к исправимому недостатку (хотя если отказываться от рамдиска, это автоматически перестаёт быть недостатком). А писать код, пока не принято решение о дальнейшей судьбе рамдиска, действительно не стоит.

Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?

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

Я тоже за RD, но дело не в этом. Можно сделать реестр библиотек, где указывается местонахождение билиотеки.
Для библиотеки должна быть точка входа, где в качестве параметра имеется ссылка на адрес для данных. В точке входа выделяется память, и идёт работа через смещения, а для каждой процедуры указывать этот адрес.

Я начал переписывать менеджер памяти. Пробный образец уже работает. Можно будет выделять память в адресном пр-ве
ядра и грузить туда драйверы и библиотеки. Для библиотек можно использовать 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 мегабайт адресов зарезервировано под ядро. Надо окончательно определится с размероми памяти ядра и памяти приложений.

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

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

Ядро отображается дважды из-за того, что планировалось перенести ядро в верхние адреса и перейти от сегментно-страничной модели памяти к чисто страничной.
Селектор 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'ов в исходниках быть не должно - они порождают слишком много проблем.