Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс июн 25, 2017 3:08 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 70 сообщений ]  На страницу 1 2 3 4 5 След.
Автор Сообщение
СообщениеДобавлено: Вс май 05, 2013 1:31 am 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Тема создана не столько с целью обсуждения, сколько с целью не забыть про необходимость изменений.
Serge писал(а):
Последний параметр не зарезервирован. Это полный путь к программе.
Код:
struc APP_HEADER_01
{ .banner      dq ?
  .version     dd ?    ;+8
  .start       dd ?    ;+12
  .i_end       dd ?    ;+16
  .mem_size    dd ?    ;+20
  .stack_top   dd ?    ;+24
  .i_param     dd ?    ;+28
  .i_icon      dd ?    ;+32       название странное, но это путь к программе
}

Максимальная длина командной строки 256 символов включая ноль. Максимальная длина пути 1024 символа включая ноль.

Поскольку статическое увеличение размера для этих двух строк не приемлемо по множеству причин, то необходимо динамическое выделение. Так что сделаю цитату своего же высказывания, чтобы не искать. Человек (в моем лице) склонен забывать некоторые свои идеи к сожалению.
Mario_r4 писал(а):
Можно create_app_space вызывать со скорректированным hdr_mem, и подменить на скорректированный адрес hdr_cmdline при вызове set_app_params. Можно сделать для всех приложений, тогда у многих останется пустая старая область в 256 байт, которую можно ликвидировать правкой кода с перекомпиляцией, либо ввести в заголовке вместо адреса особый указатель (допустим "-1" или 0xffffffff), по которому ядро будет решать действовать по старому (256 символов) или по новому (динамически выделенная память). Ядерный буфер параметров тоже придется сделать динамически выделяемым/освобождаемым, так как стека действительно может не хватить.

Будет время - займусь реализацией, если никто раньше не сделает.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 11:13 am 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
SVN r.3828 реализована поддержка расширенной командной строки. Поскольку должны быть разумные пределы, то я остановился на 64 Кб максимального размера. Этого более чем достаточно, насколько я видел существующих разделов с большими глубинами вложения директорий и файлов.
Для совместимости все старые программы оставлены в прежнем режиме - 256 символов, включая завершающий 0.

Для поддержки расширенной командной строки программ должна выглядеть приблизительно так:
Код:
   use32
   org 0x0
   db 'MENUET01'   ; 8 byte id
   dd 0x01      ; header version
   dd START   ; start of code
   dd IM_END   ; size of image
   dd I_END   ; memory for app
   dd stacktop   ; esp
   dd ext_dest_cmdline   ; I_Param
   dd path      ; APPLICATION PACH

...

ext_dest_cmdline:
   dd 0xffffffff ; тэг или флаг указывающий на наличие поддержки расширенной командной строки
   dd temp_area ; собственно сам указатель на область в 64 Кб

...

temp_area:
   rb  64*1024 ; new max cmdline 64 Kb


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

В данный момент лишь программа zSea (SVN r.3829) переделана под расширенную командую строку.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 11:48 am 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Здорово, супер. А разве ядро не может выделить памяти столько, сколько нужно для содержимого командной строки, и затем выделить её, и передать указатель? Я понимаю, что в самом лучшем случае можно сэкономить 60 килобайт ОЗУ, но интересно - такой вариант не рассматривался?


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 12:09 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
SoUrcerer писал(а):
Здорово, супер. А разве ядро не может выделить памяти столько, сколько нужно для содержимого командной строки, и затем выделить её, и передать указатель? Я понимаю, что в самом лучшем случае можно сэкономить 60 килобайт ОЗУ, но интересно - такой вариант не рассматривался?

Ядро может выделить сколько есть длины строки в текущий момент (это я просто максимальное значение ограничил) с учетом наличия максимального количества памяти, а приложению нужно уже иметь максимально выделенный объем. Так что в самом худшем случае уже будет 64+64=128 Кб.

Вопрос с очень длинными строкам (over 100500) по моему субъективному личному мнению должен решаться через именованную (расшаренную память) - это достаточно специфические случаи и держать ради этого максимальный объем еще и в запускаемом приложении немного неразумно.

SoUrcerer писал(а):
Я понимаю, что в самом лучшем случае можно сэкономить 60 килобайт ОЗУ

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 5:04 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
Mario_r4
Код:
temp_area:
   rb  64*1024 ; new max cmdline 64 Kb
Не айс. Эта память будет выделяться всегда и полностью, что не очень хорошо. Я бы предложил считать длину командной строки и прибавлять к .mem_size. Соответственно .mem_size будет будет началом строки. Учитывая постраничное выделение памяти и в большинстве случаев короткую строку, дополнительного расхода памяти не будет совсем.


Последний раз редактировалось Serge Сб июл 20, 2013 5:09 pm, всего редактировалось 1 раз.

Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 5:07 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Serge
1) Насколько я помню ты же заявлял, что менеджер памяти выделяет страницы не сразу, а лишь по факту первого обращения. Соответственно будет выделено столько, сколько записано.
2) Лично в моих программах подобные области несут многоцелевое использование, так что не пропадет.
3) Если у тебя есть "айс" варианты, то я не запрещаю их тебе реализовывать. :-)

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 5:12 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
Mario_r4
1. Это только для 68.12. Память под образ выделяется сразу.
3.Предложение в обновлённом посте выше.
Я так и сделаю, расширю "MENUET02" заголовок, или будет новый "KOLIBRI", совместимый с i386ABI.


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 5:33 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Serge писал(а):
Я так и сделаю, расширю "MENUET02" заголовок, или будет новый "KOLIBRI", совместимый с i386ABI.

Согласен. Я сам уже думал над таким подходом - сменой заголовка на "KOLIBRI", но уж больно там код укуренный - если совсем честно то ломало его осиливать, а кавалерийским наскоком не прокатило. :-)

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 6:45 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 915
Serge писал(а):
Я бы предложил считать длину командной строки и прибавлять к .mem_size. Соответственно .mem_size будет будет началом строки.
Объясни, как это будет работать, например:
Код:
db 'MENUET01'
dd 1
dd start
dd end   
dd memory
dd stack
dd params
dd path 
; code & data
start:
; code & data
params: resb PARAM_SIZE
; code & data
end:

; UPD:
resb 256
stack:
memory:

Код:
ext_dest_cmdline:
   dd 0xffffffff ; тэг или флаг указывающий на наличие поддержки расширенной командной строки
   dd temp_area ; собственно сам указатель на область в 64 Кб
Serge писал(а):
Не айс. Эта память будет выделяться всегда и полностью, что не очень хорошо.
Согласен. Почему бы тогда просто не указать, какой размер имеет область под командную строку, например, в тэге(tag = -(param_size))?


Последний раз редактировалось 0CodErr Сб июл 20, 2013 7:59 pm, всего редактировалось 1 раз.

Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 7:50 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
0CodErr
У тебя в коде метки memory нет и stack неизвестно где находится, не скомпилируется.


Вернуться к началу
СообщениеДобавлено: Сб июл 20, 2013 7:59 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 915
Serge, добавил выше метки memory и stack.


Вернуться к началу
СообщениеДобавлено: Вс июл 21, 2013 6:19 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
0CodErr
memory и mem_size из моего примера синонимы. Это количество памяти, выделяемой статически, при создании процесса. Ядру несложно увеличить это количество на длину командной строки. Память выделяется постранично, и в большинстве случаев количество страниц не увеличится.
Кстати, модифицированное предложение.
Код:
если params не равно 0 и длина командной строки не равна 0
    если длина командной строки меньше 256, копируем строку в буфер params
    иначе увеличиваем mem_size на длину командной строки + 1 байт ,
    копируем командную строку и завершающий 0,
    заменяем в заголовке params на mem_size,
    заменяем в заголовке значение mem_size на новое 
Чтобы всё работало, приложения должны брать адрес командной строки из заголовка.


Вернуться к началу
СообщениеДобавлено: Вс июл 21, 2013 6:29 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Главное для старых приложений оставить как есть, а под новый заголовок будем переписывать постепенно.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Вс июл 21, 2013 7:03 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 915
Serge писал(а):
Кстати, модифицированное предложение.
Предлагаю сделать похожим образом ещё и c path(путь к программе).
Код:
если params не равно 0 и длина командной строки не равна 0
    если длина командной строки меньше 256, копируем строку в буфер params
А если будет больше, то что делать с областью 256 байт? Если это будет уже при другом заголовке(MENUET02, например) то, может быть, лучше приложению самому не выделять вообще никогда память под параметры? Пусть ядро всегда записывает в params в заголовке адрес параметров.


Вернуться к началу
СообщениеДобавлено: Вс июл 21, 2013 7:26 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
0CodErr
256 байт будут теряться. И надо проверять код на совместимость. Так что всё это скорее имеет смысл для нового заголовка, а там может быть что угодно.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 70 сообщений ]  На страницу 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB