Да, фактически это так. Просто в документации обычно пишут PID/TID, т.к. никакого разделения пока нет.FireWall wrote:Цитата: "Ну, как минимум, идентификатор - самая важная информация о процессе."
Если Вы имеете в виду PID/TID, то это пока имено TID - идентификатор потока. Насколько я понимаю, пока в KolibriOS идентификатора процесса нет. (Поэтому я пока и продублировал возврат этого значения в двух подфункциях.)
Зарезервированные слова в SysFn09 (информация о потоке )
-
ушёл...
Вместо базового адреса, можно возвращать максимальный номер слота.
ушёл...
Адрес страничного каталога в некоторых случаях используется как pid, для поиска потоков в одном адресном пространстве.
Цитата: "Если это базовый адрес процесса, то он 0 для всех. Значение имело смысл до перехода к страничной памяти."
После некоторых размышлений я пришёл к мнению, что всё равно его надо возвращать так, как это делает SysFn09. Апгументация:
- пока планируется просто заменить SysFn09 так как есть, а потом усовершенствовать (добавив дополнительные подфункции);
- в будущем может потребоваться иметь возможность загружать некоторые приложения в любой адрес (в их виртуальной памяти), например, для того, чтобы системный сервер (также как сейчас ядро) мог бы получать доступ к данным вызвавшего его непривилегированного процесса по ссылкам без преобразования (т.е. чтобы можно было бы без больших издержек "микшировать" адресные пространства нескольких процессов).
После некоторых размышлений я пришёл к мнению, что всё равно его надо возвращать так, как это делает 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
Новый системный вызов реализован, но при более внимательном рассмотрении оказалось, что он хуже уже существующего (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
- Attachments
-
-
SysFn_alt_check.7z (117.2 KiB)
- изменённый код ядра kernel/ удалён
Downloaded 314 times
-
Who is online
Users browsing this forum: No registered users and 4 guests