Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Apr 21, 2019 12:14 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 35 posts ]  Go to page 1 2 3 Next
Author Message
PostPosted: Thu Oct 21, 2010 8:54 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
В SysFn09 (информация о потоке) имеются зарезервированные слова и байты:

+8: word:
+21 = +0x15: byte:
+52 = +0x34: word:


По этому поводу у меня вопросы:
1) В чём причина резервирования? (подозреваю, что это просто выравнивание на 4 байта, но хочу убедиться)
2) Меняется ли значение зарезервированных слов и байтов? (особенно это касается +8)
3) Есть ли в планах (когда-нибудь в будущем) использовать эти зарезервированные слова и байты?
4) Возможно ли использовать зарезервированные слова и байты? (например, для битовой маски привилегий потоков)

P.S.

Вообще-то есть ещё один вопрос общего характера:

В документации рекоментдуется выделять 1024 (= 1кб) байта для буфера. Пока реально используется только 75 байт. В чём причина более чем десятикратного запаса?


Top
   
PostPosted: Thu Oct 21, 2010 9:30 pm 
Могу точно ответит на последний вопрос - наличие зарезервированного места хорошо по умолчанию, есть куда расширять и не надо ломать мозг как добавить новое поле - добавляешь и все.

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


Top
   
PostPosted: Sat Oct 23, 2010 3:33 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Спасибо, Mario.

Но я не совсем удовлетворён ответом насчёт более чем десятикратного запаса:понятно, что зарезервированное место - это необходимо, но почему, например, не 256 байт (тройной запас)? Вот если есть далеко идущий стратегический план, который потребует около 400 - 500 байт, тогда всё становится понятно ...


Top
   
PostPosted: Sat Oct 23, 2010 4:53 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Кто-то подумал и решил, что 1Кб в самый раз. Это очень в духе Колибри, посмотри memmap.inc .


Top
   
PostPosted: Sat Oct 23, 2010 5:10 pm 
Serge
При чем тут "дух Колибри"? Это унаследовано еще с Menuet.


Top
   
PostPosted: Sat Oct 23, 2010 5:38 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

В этом плане не вижу никакой разницы. Там один байт сэкономили, тут с запасом зарезервировали.


Top
   
PostPosted: Sat Oct 23, 2010 9:08 pm 
Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?


Top
   
PostPosted: Sun Oct 24, 2010 1:29 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1301
Mario wrote:
Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?


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

имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Sun Oct 24, 2010 1:56 pm 
art_zh wrote:
имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.

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


Top
   
PostPosted: Sun Oct 24, 2010 2:03 pm 
Offline
User avatar

Joined: Wed Jan 27, 2010 10:59 am
Posts: 269
ИМХО, 1024 килобайт вполне нормальный размер для буфера. Во-первых, в той же долбанной Windows, например, есть такая структура - PEB (Process Environment Block) размером ~500 байт. Во-вторых, функция 9 возвращает пока очень мало сведений о процессе - нельзя узнать полное имя исполняемого файла, командную строку, PID/TID родителя, информацию о используемых библиотеках, об IPC, открытых шаред-мемори блоков, открытых TCP/UDP портах, дочерних потоках и т.д. и т.п. :) .
Если же жажда экономии всё-таки вас не покидает, можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).

_________________
ушёл...


Top
   
PostPosted: Sun Oct 24, 2010 3:30 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1301
Nasarus wrote:
...можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).

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

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Sun Oct 24, 2010 3:39 pm 
Offline
User avatar

Joined: Wed Jan 27, 2010 10:59 am
Posts: 269
art_zh wrote:
Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).

Не совсем понял, как таким образом можно избежать правок существующих программ.. :?:

_________________
ушёл...


Top
   
PostPosted: Sun Oct 24, 2010 3:43 pm 
Тех которые резервируют менее 1 Кб не получится не править. Впрочем большинство программ используют выделенный буфер в 1 Кб - ибо большинство программистов все-же читают документацию, так как научены горьки опытом.


Top
   
PostPosted: Sun Oct 24, 2010 7:25 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

art_zh замечательно ответил за меня. Я знаю что это тянется от Менуэт, но сваливать всё только на "темное царское прошлое" неправильно. Было достаточно времени на наведение порядка в данных ядра.

P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?


Top
   
PostPosted: Sun Oct 24, 2010 7:49 pm 
Serge wrote:
Было достаточно времени на наведение порядка в данных ядра.

Я бы ответил встречным вопросом - "так чего же сам не навел порядок?", но будет это по аналогии "драк - сам дурак". Надо учитывать что каждый занимается тем чем умеет и главное тем что ему самому нравиться - "Just for fun". Тыкать пальцем во всех и каждого бессмысленно.
Serge wrote:
P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?

Вообще-то ты скромно умалчиваешь сколько лет назад это было (мы ведь не рождаемся многомудрыми?), а также не менее скромно что я уже два года как минимум ядром не занимаюсь. Я конечно понимаю чужие недоработки видней - со стороны оно всегда видней. :lol:

И никого не трогает, что когда это делалось менеджер памяти был еще совсем "не торт", он конечно и сейчас не особо "торт" - скорее пирожок или эклер. :mrgreen:

Но может не будем сейчас заниматься выискиванием насекомых в головах и мозгах друг-друга?

Я стараюсь придерживаться одного принципа: Можешь сделать лучше другого - делай, а не сокрушайся как все плохо. Последнее контрпродуктивный подход.


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

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 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:  
Powered by phpBB® Forum Software © phpBB Limited