Board.KolibriOS.org

Jurgen, please try not to commit each line/several lines separately. Commit logically coherent pieces what implement smth

Ok

Jurgen, hello. Changes to critical areas of code, such as the MENUET header, require additional discussion because they affect many programs. Everything after the field i_icon is not standardized and is handled differently in different places (KX extension and GCC extension).
The patch that you applied, as I understand it, is only needed by your emulator. You either need to figure out how to do it differently. Or he will try to explain why such a decision is necessary. Thank you in advance.

Эта тема будет про приоритеты потоков

Винда интенсивно применяет политику приоритетов потоков при своей работе. Эти приоритеты мной игнорировались, что не мешало работе винды. Однако, когда я заметил, что число созданных потоков приближается к двустам, то резонно задуматься о внедрении в Колибри системы приоритетов пользовательских потоков.

Нашел тему в форуме "Приоритеты в планировщике задач"
http://board.kolibrios.org/viewtopic.ph ... 0%BE%D0%BA

В последнем сообщении этого форума CleverMouse сообщает о логике работы планировщика.

CleverMouse wrote: ↑Fri Jun 07, 2013 8:09 pm r3615+r3617 вносят дополнение: теперь при поступлении IRQ, отличного от таймера, также вызывается планировщик, но со специальным флагом "смотри только на потоки, которые строго более приоритетны, чем текущий". Флаг также меняет логику продвижения очереди: если пользовательский поток A упорно работал и был прерван по таймеру, то следующим пользовательским потоком будет B, следующий в кольце после A; если тот же пользовательский поток A упорно работал и был прерван по другому прерыванию, то следующим пользовательским потоком останется A - возможно, после того, как вмешавшийся ядерный поток что-нибудь сделает.

В эту логику планировщика я предлагаю добавить один пункт (выделено жирным шрифтом):
1) Если пользовательский поток A упорно работал и был прерван по таймеру, то следующим пользовательским потоком будет B, следующий в кольце после A;
2) Если у потока В снижен локальный приоритет и счетчик локального приоритета не обнулен, то переход к следующему потоку этого уровня приоритета.
3) Если тот же пользовательский поток A упорно работал и был прерван по другому прерыванию, то следующим пользовательским потоком останется A - возможно, после того, как вмешавшийся ядерный поток что-нибудь сделает.


Предлагаю следующие изменения в ядре Колибри:
1.) Добавить в структуру TASKDATA в файле const.inc два поля в свободные ячейки:

Примечание:
Я пытался просто добавить поля в структуре TASKDATA, но в итоге перестает работать кнопка "ПУСК" у Колибри. Видимо происходит затирание других данных если увеличить размер структуры. Поправьте меня, если я ошибаюсь.


2.) Внедрить код проверки ядром локальных приоритетов пользовательских потоков в файл sched.inc после метки .task_found:


3.) В процедуре set_app_params в файле taskman.inc внедрить код установки начального приоритета потока:



Уровень локальных приоритетов пользовательских потоков может быть установлен от 0 до 255 (максимально возможное значение в байте).
0 - самый высокий локальный приоритет. Этот приоритет установлен по умолчанию при запуске потока.

Продолжение следует......

Продолжение темы....

Для регулировки приложением локальных приоритетов запущенных потоков созданы новые функции:
51,3 - получить приоритет потока
51,4 - установить приоритет потока.
Заодно я создал функцию 51,2 - получить pid текущего потока чтобы не обращаться к функции 9 только для того, чтобы получить только свой pid потока.

Если не будет возражений или замечаний то, приблизительно через месяц, я внесу код в SVN и пояснения в справочник по функциям 68,24 51,2-51,4

Эта тема будет про обработку "контролируемых исключений" в ядре колибри

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

Если разработчик ядра, драйвера или приложения желает обезопасить механизм обработки данных при обращении к памяти для записи/чтения (например, к памяти полученной от пользователя), то он может сделать следующие действия:
1.) Перед обращением к памяти, установить следующие данные для обработчика "контролируемых исключений" ядра:
- В регистр edi занести сигнатуру - текст 'EXPT'
- В регистр esi занести адрес, куда должен передать управление обработчик "контролируемых исключений".
2.) По адресу, указанном в регистре esi разработчик прописывает необходимые действия в случае получения некорректных данных.


В итоге:
1. Значительно повышается стабильность (отказоустойчивость) ядра Колибри или приложения при обработке данных.
2. Упрощается алгоритм проверки данных на их корректность.
3. Этот алгоритм могут использовать разработчики приложений без обращения к функции 68,24.


Ниже показан пример применения механизма обработки некорректных данных.
Когда нам в ядро приходят непроверенные данные от пользователя, то мы устанавливаем данные для обработчика "контролируемых исключений" (строка 5593-5594).
Теперь если произойдет исключение из-за обращениия к несуществующей памяти (в строке 5596), то исполнение кода начнется с метки .err_exit: (строка 5619) с корректным завершением обработки запроса от пользователя.



В заключение предлагаю внедрить в файл sys32.inc в процедуре page_fault_exc: код обработчика "контролируемых исключений":



Если не будет возражений или замечаний, то приблизительно через месяц я внесу код в SVN, а также внесу пояснения в справочник по функции 68,24.

turbocat wrote: ↑Sat Feb 17, 2024 10:47 am Jurgen, hello. Changes to critical areas of code, such as the MENUET header, require additional discussion because they affect many programs. Everything after the field i_icon is not standardized and is handled differently in different places (KX extension and GCC extension).
The patch that you applied, as I understand it, is only needed by your emulator. You either need to figure out how to do it differently. Or he will try to explain why such a decision is necessary. Thank you in advance.

The proposed changes should not conflict with programs using other header standards. Because this handler is only fired under a few conditions:
1. A stack overflow exception occurred
2. The application is ready to handle exception 12
3. And if the application is ready to handle exception 12, then it must prepare a backup stack according to the requirement set out in the reference book for function 68.24

If the application does not fulfill the above conditions, then the stack exception handler will not run and the kernel will perform the default actions --> and an exception will occur in the kernel itself.

Jurgen,

I'm glad you managed to navigate the kernel code and even contribute to it, you're welcome. It wasn't a twenty minutes adventure, I suppose

I should have provided my feedback earlier but here it is.


1. First a non-technical thing. Could you, please, suggest your kernel changes in the kernel forum? Some people were really surprised to see your commits to the kernel because they didn't track this programs/emulators subforum at all. For example, you linked the existing topic on thread priorities in one of your previous posts. Looks like a good place to continue discussion on properties. If there is no suitable topic for the exception stack, feel free to create one. I'm sorry to put this paperwork on you. Thank you.


2. On the exception stack. Do I understand correctly that what you propose is essentially POSIX sigaltstack but without an additional syscall? In that case I have a design comment.

Firstly, if it's really POSIX anyway, then why don't we implement that particular syscall for compatibility? Maybe somebody more experienced in porting software like turbocat can say how sigaltstack is currently handled in our ports. If it would be useful to have true sigaltstack instead of a stub, then why not.

Then, in case we decide not to care about POSIX, I think the most kolibri-style way to implement the exception stack is to pass its pointer to sf68.24 in esi register. This is a very common thing for kolibri, e.g. see how esi is passed to sf4. You can then store the stack pointer to APPDATA structure, say, after pl0_stack field.

I understand that having the pointer at the fixed location in header makes it easily accessible with a single instruction. That said, there is a significant drawback too. We've got a number of app headers at the moment: MENUET00, MENUET01, MENUET02, and, unfortunately, counting. KX is a work in progress and even a PE patch exists. Having another variation, even compatible, is what we'd really like to avoid. An optional syscall argument is something one can safely ignore. Another app header variation is something a kernel developer has to always keep in their head.


3. I only looked through your recent posts on priorities so far. Is it something like POSIX nice?

Of the minuses that I have already managed to find. This is that I can't use your feature with GCC and TCC. This field is already used for other purposes. I haven't studied how signals work in POXIS, but Ivan's idea about esi seems to have a right to exist.

dunkaist wrote: ↑Sat Feb 17, 2024 2:01 pm Jurgen,
.....
1. First a non-technical thing. Could you, please, suggest your kernel changes in the kernel forum? Some people were really surprised to see your commits to the kernel because they didn't track this programs/emulators subforum at all. For example, you linked the existing topic on thread priorities in one of your previous posts. Looks like a good place to continue discussion on properties. If there is no suitable topic for the exception stack, feel free to create one. I'm sorry to put this paperwork on you. Thank you.
.....

Okay, I will repost on thread priorities and stack exclusion in the kernel forum and in future I will post everything related to changes in the kernel on the kernel forum.

What complies with the forum rules - to create separate topics for individual proposals for editing the kernel, or to make one topic like “Windows OS emulator and kernel changes” and post all proposals for editing the kernel there?

dunkaist wrote: ↑Sat Feb 17, 2024 2:01 pm .....
Then, in case we decide not to care about POSIX, I think the most kolibri-style way to implement the exception stack is to pass its pointer to sf68.24 in esi register. This is a very common thing for kolibri, e.g. see how esi is passed to sf4. You can then store the stack pointer to APPDATA structure, say, after pl0_stack field.
.....

turbocat wrote: ↑Sat Feb 17, 2024 2:30 pm Of the minuses that I have already managed to find. This is that I can't use your feature with GCC and TCC. This field is already used for other purposes. I haven't studied how signals work in POXIS, but Ivan's idea about esi seems to have a right to exist.

Fine. I'll rework the stack exception handling mechanism by passing the address of the backup stack to esi register in function 68.24 and post this variant on the kernel forum for discussion.

dunkaist wrote: ↑Sat Feb 17, 2024 2:01 pm ....
3. I only looked through your recent posts on priorities so far. Is it something like POSIX nice?

I try to stick to the Kolibri OS standards. If I'm wrong somewhere, you and others will correct me.

Jurgen wrote: ↑Sun Feb 18, 2024 7:37 am Okay, I will repost on thread priorities and stack exclusion in the kernel forum and in future I will post everything related to changes in the kernel on the kernel forum.

What complies with the forum rules - to create separate topics for individual proposals for editing the kernel, or to make one topic like “Windows OS emulator and kernel changes” and post all proposals for editing the kernel there?

You don't have to create a separate topic for each change. There is a topic on thread priorities already, you mentioned it. Same for exception handling: one, two. Feel free to just post links to the existing messages in this topic to the kernel forum and then continue kernel-related discussion there. Maybe moderators will move posts around then. We aren't strict about forum rules at all, but it's desirable for a significant kernel change to leave at least some trace in the kernel forum. It will be much easier later to track logic behind the changes, thank you.

Jurgen wrote: ↑Sun Feb 18, 2024 7:37 am Fine. I'll rework the stack exception handling mechanism by passing the address of the backup stack to esi register in function 68.24 and post this variant on the kernel forum for discussion.

I'd appreciate this, everybody should be happy then. Sorry again for my late feedback.

Jurgen wrote: ↑Sat Feb 17, 2024 10:57 am Примечание:
Я пытался просто добавить поля в структуре TASKDATA, но в итоге перестает работать кнопка "ПУСК" у Колибри. Видимо происходит затирание других данных если увеличить размер структуры. Поправьте меня, если я ошибаюсь.

You're right, sizeof.TASKDATA is expected to equal 32. Unfortunately, kernel code isn't flexible about it at the moment.

Jurgen wrote: ↑Sat Feb 17, 2024 11:10 am 51,3 - получить приоритет потока
51,4 - установить приоритет потока.
Заодно я создал функцию 51,2 - получить pid текущего потока чтобы не обращаться к функции 9 только для того, чтобы получить только свой pid потока.

I'd prefer to move 51.2 closer to sf9 or implement it as a subfunction. Up to you though.

Сообщаю для всех, кто отслеживает ход разработки эмулятора.

Все посты, связанные с предложениями по правке ядра Колибри, я буду выкладывать в теме "Эмулятор ядра OS Windows и правки ядра Колибри"
http://board.kolibrios.org/viewtopic.php?t=5627

Здесь в дальнейшем будут выкладываться посты не связанные с предложениями по правке ядра Колибри.

Jurgen,

I can't build your project because of 'masm.inc' file that is missing. Could you share it?

fasm wrote:$ fasm -m 1234567 WCore.asm wcore
flat assembler version 1.73.32 (1234567 kilobytes memory, x64)
WCore.asm [16]:
include "masm.inc"
error: file not found.

Этот файл не нужен.(Забыл ранее закомментить).
Вы можете закомментировать или удалить эту строку в WCore.asm [16].

На всякий случай выкладываю этот файл