Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Jul 16, 2019 7:41 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 17 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Tue May 12, 2009 8:11 am 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Отрезано от темы

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


Top
   
PostPosted: Tue May 12, 2009 8:30 am 
Ghost
Я понимаю конечно что ты специалист неплохой как минимум, но мог бы ты нам непрофесионалам объяснить что сие имелось ввиду?

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


Top
   
PostPosted: Tue May 12, 2009 8:42 am 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Файлы проецируемые в память, это концепция работы с файлами, суть которой в том что работа с файлом организуется как с массивом в памяти. Писатель из меня хреновый, поэтому перенаправляю к Рихтеру, там все подробно рассписано, часть относящуюся в особенностям реализации в Win можно пропустить, для понимания она не нужна.


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


Top
   
PostPosted: Tue May 12, 2009 9:14 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Ghost
MMF в данном контексте ни при чём (файлы в памяти имеют совершенно не такой вид, как на диске - как исполняемые, так и библиотеки). А вот разделение памяти между разными экземплярами одной и той же загруженной библиотеки пригодилось бы.

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


Top
   
PostPosted: Tue May 12, 2009 11:02 am 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
diamond почему же не такой? если ещё и внести в головы прикладных разработчиков идею о разделении кода и данных, на сегментах кода можно экономить память, а если данные не модифицируются то и на сбросе кеша можно попробывать экономить. Ну а с библиотеками, с учетом того что вероятность их многократной загрузки намного больше чем приложений - само собой пригодится. Ну и размышляя далее, таким образом несложно получить разделяемую память...


Top
   
PostPosted: Tue May 12, 2009 11:55 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
diamond wrote:
А вот разделение памяти между разными экземплярами одной и той же загруженной библиотеки пригодилось бы

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

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


Top
   
PostPosted: Tue May 12, 2009 12:00 pm 
Offline

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


Top
   
PostPosted: Tue May 12, 2009 12:13 pm 
Offline
Kernel Developer
User avatar

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


Top
   
PostPosted: Tue May 12, 2009 12:38 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Ghost wrote:
Плох вариант тем что за счет не привязанности кода к адресам, получаем много лишних обвесок (хотя по сути они нужны для глобальных переменных и call`ов)
И еще тем, что замахаешься кодить в эдаком стиле :)
Ghost wrote:
Другой вариант - твои нижние 2 гига, почему нет?
Ну не совсем мой :)
Мне пока больше нравятся как раз верхние 2Г. Ну типа: хип ядра растет снизу (с "2Г" - вверх), а "системные либы" лепятся сверху (от 4Г - вниз), и имееют одинаковые адреса для всех процессов и для ядра
Тоже спрошу - почему нет ???
И кстати, следует ЛИ делить либы на "системные", и "общечеловеческие" ???

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


Top
   
PostPosted: Tue May 12, 2009 12:44 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Ghost
Ещё раз: приложения и библиотеки на диске имеют совершенно другой вид, чем в памяти независимо от того, выделены сегменты кода и данных или нет. Потому что ядро умеет грузить kpack'ованные приложения.
Похоже, ты путаешь концепцию memory-mapped files и разделяемую память. Это совершенно независимые вещи. То, что можно спроецировать одну и ту же физическую страницу с кодом в адресное пространство двух разных процессов, никак не связано с тем, что можно привязать страницу в памяти к странице на диске.
Galkov
Делать допущение
Quote:
Раз память единая, значит единый адрес для всех процессов.

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

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

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


Top
   
PostPosted: Tue May 12, 2009 1:30 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
diamond wrote:
Одну и ту же физическую страницу можно отобразить на совершенно разные логические адреса
Да это как раз понятно. Я имел в виду виндячую систему: другой адрес => изменения от релокации => срабатывает (а куда деваться-то) COPY_ON_WRITE - получается именно то самое "идет лесом".

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

diamond wrote:
Неправильная точка зрения.

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

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


Top
   
PostPosted: Tue May 12, 2009 1:34 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
diamond не путаю, просто одновременно всё в голове крутится )), на самом деле тут три идеи, MMF, разделяемая память и подкачка (или виртуальной памятью это правильнее назвать?). Про kpack за неиспользованием забыл.
Quote:
и если загрузчик не смог загрузить библиотеку по этому адресу, то разделение страниц между процессами идёт лесом

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


Top
   
PostPosted: Tue May 12, 2009 1:48 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Тема viewtopic.php?f=2&t=32 , дубль 2?
Quote:
А как работает либа в "неродном" адресном пространстве? есть например у нас две либы с одним предпочтительным адресом?

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

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


Top
   
PostPosted: Tue May 12, 2009 4:00 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
Как человек, обладающий только теоретическими знаниями по ядростроению, а не практическими навыками хочу заключить следующее (возможно я и ошибаюсь):

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 17 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
Powered by phpBB® Forum Software © phpBB Limited