Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Jul 31, 2021 3:00 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 21 posts ]  Go to page Previous 1 2
Author Message
PostPosted: Wed Mar 03, 2021 9:18 am 
Offline
User avatar

Joined: Tue Jan 26, 2021 3:38 am
Posts: 36
ProMiNick, runkx пользуется только теми возможностями, которые ему предоставляет ядро, так что управление памятью выполняется с помощью соответствующих системных вызовов. Загрузчик был сделан именно для тестирования формата, тем более, что никакого специального API для создания процессов нет (кроме sf70.7/80.7, которые не умеют в произвольные форматы) и приходится использовать существующий механизм отладки. Добавлять загрузку в ядро имеет смысл лишь в том случае, если KX окажется полезным и будет нужен.


Top
   
PostPosted: Wed Mar 03, 2021 9:59 am 
Offline
User avatar

Joined: Tue Jan 26, 2021 3:38 am
Posts: 36
ProMiNick wrote:
управление памятью в пространстве адресов процесса вещь интересная. Она может быть реализована в юзермод лоадером?

Даже с помощью функций 64.1 и 68.12/68.13/68.20 и т.д. уже можно управлять памятью нового процесса. Например, первый вариант (скорее всего, можно ещё проще и изящнее сделать), который приходит на ум:
  1. загрузчик устанавливает с помощью 64.1 размер своей памяти в размер_образа_исполняемого_файла + размер_неинициализированных_данных + размер_стэка
  2. затем инициирует кучу (кстати, как известно, с этого момента 64.1 нельзя уже использовать) и выделяет блок памяти для кода, который будет записывать/загружать образ
  3. копирует этот код в динамически выделенный блок (желательно, чтобы код был позиционно-независимым, иначе придётся пересчитывать адреса)
  4. загружает образ в память, выделенную с помощью функции 64.1
  5. устанавливает новую вершину стэка
  6. обнуляет регистры, настраивает окружение процесса
  7. каким-то образом очищает память, выделенную для кода загрузки (вот это непросто будет сделать)
  8. делает переход на точку входа (которая, например, указана в полях заголовка)
Если код должен загружаться не по нулевому адресу, то ничего толкового не выйдет - нужно будет либо драйвер писать, либо ядро ковырять. Главный и единственный минус такой схемы - это то, что нельзя переименовать процесс (он так и останется "х-loader"). Поэтому для runkx этот вариант не подошёл.


Top
   
PostPosted: Wed Mar 03, 2021 3:57 pm 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 471
Ну лоадер - решение временное, как я понимаю. Потому библиотеки достаточно грузить просто, каждому процессу по экземпляру. Конечно, когда и если это будет переносится в ядро, загрузчик будет уже библиотеки грузить как положено. Данные каждому, код всем общий.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
PostPosted: Wed Mar 03, 2021 4:31 pm 
Offline
User avatar

Joined: Tue Jan 26, 2021 3:38 am
Posts: 36
GerdtR wrote:
Ну лоадер - решение временное, как я понимаю. Потому библиотеки достаточно грузить просто, каждому процессу по экземпляру. Конечно, когда и если это будет переносится в ядро, загрузчик будет уже библиотеки грузить как положено. Данные каждому, код всем общий.

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


Top
   
PostPosted: Thu Apr 29, 2021 11:44 pm 
Offline

Joined: Tue Apr 09, 2019 8:57 pm
Posts: 58
Привет!
Тоже задумывался над новым форматом, но немного с другими, более системными идеями. К названию в итоге пришел к такому же, т.е. KX (ты не поверишь), поэтому оно мне нравится.
Новый формат необходим, во-первых для того, чтобы реализовать полноценную поддержку автозагрузки библиотек, а во-вторых сделать единый формат для приложений (*.kxa), библиотек (*.kxl) и драйверов (*.kxd) и т.п.. Сейчас с этим творится какой-то хаос: приложения используют формат MENUET01 (также есть версия MENUET02 и еще самый древний MENUET00), библиотеки - COFF и даже PE, драйверы только PE. И соответственно в ядре живет код для всего этого зоопарка форматов, почему нельзя сделать единый формат для всего?
Не понимаю, что тут делает PE - он не вписывается в философию Kolibri, его особенность в использовании с дисковой памятью (полноценная идея PE в том, что он состоит из секций и мапится в память нужными участками, а когда нужно, если секция не менялась в памяти, можно без проблем ее выгрузить без задействования файла подкачки и в нужное время загрузить заново), которой в Kolibri нет.
Например, у PE часть секций для выравнивания заполнена нулями - зачем ее хранить на диске если она все равно в Kolibri никогда там не будет использована? Загрузчику ничего не стоит дополнить неиспользуемые части страницы нулями.

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

1. Защита страниц кода и константных данных. Сейчас вся пользовательская память доступна для чтения и записи. Т.е. по ошибке можно затереть код и/или данные и получить сюрпризы (я с таким уже столкнулся в Kolibri - искать такие баги крайне сложно). Потери памяти от этой полезной функции небольшие, как минимум тратится лишняя страница в 4 кБ.
2. не хранить на диске и не загружать в память лишнюю информацию. Например, не хранить в образе указатели импорта, а только ссылаться на нужные участки, которые будут доступны только при загрузке в память. Не загружать заголовок и таблицы, которые нужны нужны только загрузчику (зачем это в памяти?), т.е. загружать только код и данные
3 . TLS (локальная память потока) - зачатки этого в ядре уже имеются
...

Считаю, надо прийти к общей системной идее по новому формату, который затем еще нужно обкатывать. Либо дорабатывать какой-то имеющийся хорошо известный и давно используемый формат, скажем COFF (он больше подходит под философию Kolibri с учетом описанных выше идей, к тому же поддерживается многими компиляторами и поддерживается ядром и давно используется), т.е. делать надстройку над существующим форматом.

По предложенной спецификации увидел несколько интересных идей, но есть и недостатки, ну и спецификация не охватывает много нужных особенностей.

Недостатки:
1. зачем UTF-8? Для символов и имени библиотеки достаточно ASCII, это общепринятый стандарт.
2. очевидно, что самый компактный вариант чанка - 8 бит, как я понял он задается один раз и остальными вариантами уже не воспользуешься.
3. зачем столько флагов по сжатию, почему нельзя просто сжать все кроме заголовка? Не понял, как распаковщик узнает какой размер будет после распаковки (какой надо выделить буфер)?
4. как загрузчик узнает где конец образа для загрузки (какой ему надо выделить выделить буфер)?
5. Таблица импорта состоит из массива указателей и строк. Как загрузчик узнает размер массива указателей? зачем нужны указатели (это увеличивает размер таблицы) если строки следуют друг за другом? Строки достаточно разделить между собой. А указатель на таблицу строк зачем? Очевидно же, что он идет после массива указателей, к тому же все указатели от начала файла.
6. Не понял, где указатели импорта, которые заполняет загрузчик?
7. Почему нет таблицы экспорта?
8. Если это библиотека (драйвер), то адрес загрузки может измениться. Как загрузчик поймет какие участки образа надо править в этом случае?
9. Как узнать командную строку?
...


Top
   
PostPosted: Tue Jun 08, 2021 9:44 am 
Offline

Joined: Mon Sep 07, 2020 1:54 pm
Posts: 12
Когда будет дальнейшая работа по развитию формата КХ? Подвижки хоть какие то есть?


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

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


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