Board.KolibriOS.org

FireWall wrote:Цитата: "Ну, как минимум, идентификатор - самая важная информация о процессе."

Если Вы имеете в виду PID/TID, то это пока имено TID - идентификатор потока. Насколько я понимаю, пока в KolibriOS идентификатора процесса нет. (Поэтому я пока и продублировал возврат этого значения в двух подфункциях.)

Да, фактически это так. Просто в документации обычно пишут PID/TID, т.к. никакого разделения пока нет.

Вместо базового адреса, можно возвращать максимальный номер слота.

Адрес страничного каталога в некоторых случаях используется как pid, для поиска потоков в одном адресном пространстве.

Цитата: "Если это базовый адрес процесса, то он 0 для всех. Значение имело смысл до перехода к страничной памяти."

После некоторых размышлений я пришёл к мнению, что всё равно его надо возвращать так, как это делает SysFn09. Апгументация:
- пока планируется просто заменить SysFn09 так как есть, а потом усовершенствовать (добавив дополнительные подфункции);
- в будущем может потребоваться иметь возможность загружать некоторые приложения в любой адрес (в их виртуальной памяти), например, для того, чтобы системный сервер (также как сейчас ядро) мог бы получать доступ к данным вызвавшего его непривилегированного процесса по ссылкам без преобразования (т.е. чтобы можно было бы без больших издержек "микшировать" адресные пространства нескольких процессов).

Пожалуй всё-же придётся "перевернуть эту страницу"

Новый системный вызов реализован, но при более внимательном рассмотрении оказалось, что он хуже уже существующего (SysFn09). Как говориться: "Отрицательный результат - это тоже результат."

Почему хуже?
(1) Не даёт выигрыша в скорости (ибо в SysFn09 основное время занимает переключение ring3 -> ring0 -> ring3).
(2) Не даёт выигрыша в размере исполняемого файла, так как буфер на 1024 байта (что конечно расточительно) можно хранить в BSS либо даже в динамически выделенном блоке.
(3) Также и даже ещё более неудобен для C-обёртки

P.S

Чтобы не подумали, что мне просто слабо реализовать эту идею - в прикреплённом файле (SysFn_alt_check.7z) находится реализация...

Содержимое архива:

libkosw.a – статическая библиотека, используемая для alt_ch.kex (начальный эскиз в отладочной версии; исходники находятся в папке src)
остальные файлы - проект изменённого ядра с новым системным вызовом, а также тестовой программы.

bin/

alt_ch.kex – программа, показывающая идентичность результатов нового системного вызова (содержащегося в kernel.mnt, находящемся здесь же) и SysFn9 для непустых слотов;

kernel.mnt – ядро ($Revision: 2640 $) с новым системным вызовом, помещённым вместо зарезервированной системной функции 27;

cpu_count.kex – программа, сравнивающее время исполнения (в тиках процессора):
- собственно затрачиваемое на саму функцию
- затрачиваемую на зарезервированную системную функцию SysFn19 с собстенно кодом (+ сама функция):
paleholder:
ret ; kernel.asm строчка 5214
- затрачиваемое на SysFn9 (+ сама функция).
Исходники программы также находятся в src/ .

include/

Здесь находятся заголовочные файлы для libkosw.a (совпадают с соответствующими из папки src/ ).

kernel_changed/

Здесь находятся новые или изменённые файлы ядра (с сохранением относительного расположения):

kernel32.inc – изменённые строчки (248 – 251):
; < FireWall>
; new system functions
include "process_thread_info.inc"
; < /FireWall>

process_thread_info.inc – файл, содержащий код нового системного вызова (ничего нового – это слегка реструктурированный код SysFn9);

core/syscall.inc – изменённые строчки (150 - 153):
; < FireWall>
dd proc_thread_info ; 27-Process and thread info (alternative for SysFn09)
; < /FireWall>
; dd undefined_syscall ; 27-reserved