Board.KolibriOS.org

В SysFn09 (информация о потоке) имеются зарезервированные слова и байты:

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

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

P.S.

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

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

Могу точно ответит на последний вопрос - наличие зарезервированного места хорошо по умолчанию, есть куда расширять и не надо ломать мозг как добавить новое поле - добавляешь и все.

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

Спасибо, Mario.

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

Кто-то подумал и решил, что 1Кб в самый раз. Это очень в духе Колибри, посмотри memmap.inc .

Serge
При чем тут "дух Колибри"? Это унаследовано еще с Menuet.

Mario

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

Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?

Mario wrote:Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?

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

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

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

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

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

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

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

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

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

Тех которые резервируют менее 1 Кб не получится не править. Впрочем большинство программ используют выделенный буфер в 1 Кб - ибо большинство программистов все-же читают документацию, так как научены горьки опытом.

Mario

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

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

Serge wrote:Было достаточно времени на наведение порядка в данных ядра.

Я бы ответил встречным вопросом - "так чего же сам не навел порядок?", но будет это по аналогии "драк - сам дурак". Надо учитывать что каждый занимается тем чем умеет и главное тем что ему самому нравиться - "Just for fun". Тыкать пальцем во всех и каждого бессмысленно.

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

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

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

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

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