| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Ядро 3OS | |||
|
|||
 Менеджер памятиПерейти к странице -1-2 Следующая |
| Автор | Отправлено |
| ReMY |
|
||
Местоположение: Москва Сообщений - 1 |
Люди очень хотелось бы знать, как в реализовали работу с памятью у вас в ОС. И если можно то сказать где вы взяли документацию, просто весь инет из рыскал ничего не нашел. Или если не сложно то привести исходный код менеджера, ну хотя бы кусочка =). Заранее очень благодарен! | ||
| Наверх |
|
| AlexanderK |
|
||
Местоположение: 2:5020/829.5 Сообщений - 49 |
Ты кого спрашиваешь? Здесь нет уж никого. Я написал кое-какой менеджер PhysAllocPage(); LocalAlloc(UINT nSize); GlobalAlloc(UINT nSize); на http://sourceforge.net/project/showfiles.php?group_id=64078&package_id=127379&release_id=261310 |
||
| Наверх |
|
| Pushkoff |
|
||
|
Местоположение: Донецк Сообщений - 13 |
А зачем в 32 разрядной среде 2 типа функций выделения памяти??? Ведь все адреса ближние (по крайней мере в модели flat)... Или я чего-то не понял?.. | ||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Просто в ОС память подразделяется на 2 региона - локальная, которая доступна только самой задаче (изолированное адресное пространство), и глобальная (общее адресное пространство), доступная всем. Соответственно программа может выбирать, какая память ей нужна. | ||
| Наверх |
|
| Pushkoff |
|
||
|
Местоположение: Донецк Сообщений - 13 |
Это было в досе... в win память делится на пользовательскую и системную... системную память может выделять только система. А локальную и глобальную память выделяет программа, причем во многих книгах написано что это одно и то же и оставлено для совместимости со старыми версиями, и выделяют они память доступную только данному процессу. | ||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Ты оказывается про виндовс, я сразу не понял, извиняюсь. | ||
| Наверх |
|
| Pushkoff |
|
||
|
Местоположение: Донецк Сообщений - 13 |
Ниччо... Просто в предложенном выше менеджере одна из функций лишняя (Local bkb Global)... ведь можно использовать одну и ту же функцию для системы и для программы, только подавать им разные адреса кучи (процедура определяет кто её вызвал (хотябы по уровню привелегий CPL) и берет нужную кучу). По моему рано писать менеджер памяти, ведь её еще не распредилили (канкретно адреса где будет хранится ГДТ, ИДТ, Таблици старниц, память системы/приложения и тд), ты сегодня пишешь Локал и Глобал алок, а они завтра придумают 10 куч для разных обьектов... По моему с этого (распределения памяти физической и виртуальной) надо было начать... |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Это у меня элементарные функции ядра, а ядру нужна возможность выделять и локальную и глобальную память. Менеджер не мешает выделять память по конкретным адресам. А GDT на начальном этапе статическая. [ Редактирование Friday 11.11.2005 17:55 ] |
||
| Наверх |
|
| Pushkoff |
|
||
|
Местоположение: Донецк Сообщений - 13 |
GDT и на конечном этапе будет статическая. Максимальный её размер 64к. А я не думаю что одной из современных ос нужно больше 2000 дескрипторов. Если память сейчас считается метрами то 64к не жалко... Я имел ввиду, что надо определится с канкретными адресами в физической памяти где будет храниться GDT, LDT, IDT и адреса процессов в которые будут проецироваться эти таблицы, ядро, системная память и тд (составить карту распределения памяти)... Я предлагаю такую идею: когда процесс запрашивает память, ядро видит что этот запрос от процесса и подставляет его кучу, а когда ядру нужна память оно просто берет нужную кучу и выделяет в ней... Остается одна универсальная функция... Приложению нельзя разрешать выделять системную память, поэтому ядро не должно предоставлять такого сервиса... |
||
| Наверх |
|
| Pushkoff |
|
||
|
Местоположение: Донецк Сообщений - 13 |
Хотя я тоже гоню... Зачем вызывать функцию ядра на выделение памяти, если память может выделить само приложение, было бы только где (так делал дос функцией малок)... Ядро должно уметь предоставлять пользователю кучу, с которой он может делать все что угодно. А при хорошем механизме подкачки и куча не нужна, пользователь для своих нужд может использовать всю свободную отведенную ему память, а функции выделения и пр. можно свести в одну библиотеку (пользовательскую) и при этом вообще не обращаться к ядру... при обращении к любому участку памяти в свопе создается для него страница куда он потом будет скинут. благо архитектура позволяет (в таблице страниц флаг Д - "грязная страница", при обращении к ней будет исключение)... Следовательно, нужда в функциях выделения пользовательской памяти на стадии разработки ядра исчезает... Теперь нужно реальзовывать менеджер подкачки... |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Pushkoff писал(а): ... Я имел ввиду, что надо определится с канкретными адресами в физической памяти где будет храниться GDT, LDT, IDT и адреса процессов в которые будут проецироваться эти таблицы, ядро, системная память и тд (составить карту распределения памяти)... В моей системе это всё уже распределено. Но я ей уже не занимаюсь, надоело. Pushkoff писал(а): ... Следовательно, нужда в функциях выделения пользовательской памяти на стадии разработки ядра исчезает... Да, я думаю можно и так. |
||
| Наверх |
|
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |