Board.KolibriOS.org

Отрезано от темы

Луще если бы сообщество дошло до осознания необходимости файлов проецируемых в память, а не гонялось за экономией в 927 байт )))

Ghost
Я понимаю конечно что ты специалист неплохой как минимум, но мог бы ты нам непрофесионалам объяснить что сие имелось ввиду?

Даже то что наработано не используется, но переиодически люди начинают вопить:
1) Лучше микроядро
2) Лучше Си
3) Лучше портировать...
При этом никто этим заниматься из кричащих не собирается.

Файлы проецируемые в память, это концепция работы с файлами, суть которой в том что работа с файлом организуется как с массивом в памяти. Писатель из меня хреновый, поэтому перенаправляю к Рихтеру, там все подробно рассписано, часть относящуюся в особенностям реализации в Win можно пропустить, для понимания она не нужна.

Ghost
Так, в кратце ознакомился, но вот что меня смущает - реализация очень смахивает на реализацию файла подкачки для виртуального адресного пространства. Мне так кажется не все так просто, хотя подход надо признать интересный и перспективный. Но я лично его не осилю с большой вероятностью. И раз уж ты предложил идею - возникает вопрос на миллион: You ready?

Ghost
MMF в данном контексте ни при чём (файлы в памяти имеют совершенно не такой вид, как на диске - как исполняемые, так и библиотеки). А вот разделение памяти между разными экземплярами одной и той же загруженной библиотеки пригодилось бы.

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

diamond почему же не такой? если ещё и внести в головы прикладных разработчиков идею о разделении кода и данных, на сегментах кода можно экономить память, а если данные не модифицируются то и на сбросе кеша можно попробывать экономить. Ну а с библиотеками, с учетом того что вероятность их многократной загрузки намного больше чем приложений - само собой пригодится. Ну и размышляя далее, таким образом несложно получить разделяемую память...

Здесь нужна концепция какая-то. Раз память единая, значит единый адрес для всех процессов.
В том числе и для сегментов данных (этой же либы), которые как раз и НЕ должны разделяться всеми процессами.
И где интересно такая область логических адресов расположена ???
Если в нижних 2-х гигах, то это может явиться неожиданностью для процессов не использующих эту либу... Ну вроде бы память и есть, а ее на самом деле уже и нет...
Это для всех либов так, или только для некоторых ???

Ну и еще куча аналогичных вопросов, постановочного характера.
Определенность в этих вопросах -- и можно было бы приступать к делу.
Но вас же разговорить - не самая тривиальная задача. Каждый почему-то боится высказать идею, у которой есть риск оказаться неправильной
Ей богу, такой стиль совместной разработки - не самый оптимальный, ИМХО.
Ну вот и имеем, не более чем "хорошо бы"

ЗЫ: кстати делал где-то (сразу и не найду): Технология MMF может явиться "переходником" между 32-х битными стримами, и "шибко длинными" реальными файлами.
Ну типа выкидывается окно из этого файла, с которым ты уже можешь работать с 32-х битными библиотечными ф-ями.

Ну тут несколько подходов, например как делается вроде в ELF, весь код библиотеки не привязан к адресам, таким образом его можно пристегивать к любым адресам процесса, просто динамически выделяея в контексте процесса необходимую память, ни о каких "верхних 2Гб" думать не надо. Плох вариант тем что за счет не привязанности кода к адресам, получаем много лишних обвесок (хотя по сути они нужны для глобальных переменных и call`ов).
Другой вариант - твои нижние 2 гига, почему нет? или у нас есть приложения использующие столько памяти?

И еще тем, что замахаешься кодить в эдаком стиле
Ну не совсем мой
Мне пока больше нравятся как раз верхние 2Г. Ну типа: хип ядра растет снизу (с "2Г" - вверх), а "системные либы" лепятся сверху (от 4Г - вниз), и имееют одинаковые адреса для всех процессов и для ядра
Тоже спрошу - почему нет ???
И кстати, следует ЛИ делить либы на "системные", и "общечеловеческие" ???

Кстати, было где-то на этом форуме: у чела не прилепилась в винде какая-то системная либа, типа -- место уже занято...

Ghost
Ещё раз: приложения и библиотеки на диске имеют совершенно другой вид, чем в памяти независимо от того, выделены сегменты кода и данных или нет. Потому что ядро умеет грузить kpack'ованные приложения.
Похоже, ты путаешь концепцию memory-mapped files и разделяемую память. Это совершенно независимые вещи. То, что можно спроецировать одну и ту же физическую страницу с кодом в адресное пространство двух разных процессов, никак не связано с тем, что можно привязать страницу в памяти к странице на диске.
Galkov
Делать допущение

совершенно не обязательно. Одну и ту же физическую страницу можно отобразить на совершенно разные логические адреса.
Насчёт проблем с тем, что в библиотеке код может быть привязан к адресу загрузки библиотеки, - есть несколько возможных решений. В Linux принято делать в разделяемых библиотеках position-independent code, что означает лишний код и лишнюю задержку в каждой функции (или, по крайней мере, в каждой "торчащей наружу" функции) для получения загруженной базы и, что ещё хуже, резервирование одного регистра под эту базу (учитывая, что в x86 регистров общего назначения всего 7, это актуально). В Windows принято в разделяемых библиотеках указывать предпочтительный адрес загрузки, и если загрузчик не смог загрузить библиотеку по этому адресу, то разделение страниц между процессами идёт лесом. В x64 с этим проще, поскольку там наконец появилась rip-relative адресация. Я за Windows-схему.

Неправильная точка зрения. Все, кто работает, не любят высказывать идеи, которые они не готовы реализовывать, а все, кто не работает, кричат "дайте то-то" или "сделайте то-то" в соответствующих темах, не доходя до ядра.

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

Да это как раз понятно. Я имел в виду виндячую систему: другой адрес => изменения от релокации => срабатывает (а куда деваться-то) COPY_ON_WRITE - получается именно то самое "идет лесом".

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


Это еще не точка зрения. Это сложившееся ПОКА ощущение
Ну вот Вам и тест на разговорчивость (таких есть у меня):
1) Показалось мне, что встречавшиеся фразы про "тяжесть переключения задач в текущей реализации" (может быть не очень точно - пишу по памяти) связаны с ожиданием, которое осуществляется вызовом do_change_task В ЦИКЛЕ.
2) Смотрю в коды. Ну ничего вроде венного - и больше порой пишут. Остановился на том, что "тяжесть" заключается в изменении CR3
3) Прав я или нет - фиг его знает, не имею я опыта программирования в 0-м кольце.
4) Исходя из своих предположений (возможно, не очень точных) сотворил иную технику ожидания - event.inc::Wait_events[_ex]
5) Коллеги, но никто ведь не сказал ни - "ай как хорошо", ни - "а на фига козе баян"
6) Можно конкретизировать вопрос до предела: переделать 5-ю ф-ю с использованием Wait_events_ex (ф-я ожидания возвращает тождественный нуль - все становится сверх-тривиальным) - ЭТО ПРАВИЛЬНО, ИЛИ НЕТ

Это как бы я хотел обратить внимание на то, что каким-то путем я таки двинулся, а коллеги молча смотрят (имея значительно больший опыт на этих "горных трассах")

diamond не путаю, просто одновременно всё в голове крутится )), на самом деле тут три идеи, MMF, разделяемая память и подкачка (или виртуальной памятью это правильнее назвать?). Про kpack за неиспользованием забыл.

А как работает либа в "неродном" адресном пространстве? есть например у нас две либы с одним предпочтительным адресом?

Тема viewtopic.php?f=2&t=32 , дубль 2?

Есть таблица перемещаемых элементов (кстати, в используемом сейчас COFF она тоже есть, и сейчас в Колибри всё происходит так же за вычетом того, что нет предпочтительного адреса загрузки), и при загрузке не по родному адресу происходит коррекция всех адресов. Это несколько замедляет загрузку (по сравнению с концепцией Linux) за счёт отсутствия замедления при работе (по сравнению с той же концепцией).

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

Как человек, обладающий только теоретическими знаниями по ядростроению, а не практическими навыками хочу заключить следующее (возможно я и ошибаюсь):

Описанная проблема мне напоминает пасьянс - надо знать откуда брать карты, куда и перекладывать и как это делать. "Откуда" определяется форматом исполняемого файла/библиотеки, "куда" - архитектурой ЭВМ, "как" - алгоритмом соответствующей процедуры ядра (загрузчиком).

Мои соображения: определиться с форматом файлов (я не предлагаю кардинально переходить на ELF или PE, хотя ИМХО было бы не плохо), насчёт вопросов реализации - это дело ядерщиков... Немногие сумеют решить эту непростую задачу... Большой "плюс" - то, что проблема не горит... (система работает стабильно, памяти вроде хватает...)