Гут. Тогда продолжим...

По поводу Монитора остается вопрос корректности его работы у разных ЦП, при числе кэшей у ЦП более 4х.

При желании, Вы можете у себя проверить корректность работы моего Монитора.. Для этого:
а) Скачать и запустить у себя iso образ ядра Колибри v.2 (см ссылку ниже)
б) После запуска системы Колибри посмотреть, есть ли «ложное» срабатывание Монитора с сообщением в Board. Для этого:
Запустить Board и нажать в нем кнопку «User”
Сообщение Монитора в Board в формате: «Thread CPU Usage more 5 sec. …....” через каждые 5 сек.
Если нет ложного срабатывания, тогда следующий пункт.


в) Перейти к минипроге CHECK_MONITOR:
(Нажать кн. «Меню» → Система → Файловые менеджеры → Eolite → В списке «Устройства» кликнуть на «CD-Rom ….” )


г) Запустить эту минипрогу в отладчике mtdbg:
(Кликнуть правой кнопкой мыши по файлу CHECK_MONITOR → Выбрать в подменю «Запустить с помощью....» → В появившемся окне кликнуть на кнопку «Обзор» → Дважды кликнуть по папке «DEVELOP” → В списке файлов найти файл “MTDBG” и дважды кликнуть по нему → Нажать на клавишу «G” → Нажать на клавишу. «Enter” и запустится программа в отладчике)

И проверить:
1) Появится ли .через 5 сек. сообщение в Board (Запустить Board и нажать кнопку «User”)
2) Если появится, то проверить в сообщении корректность указанного адреса «проблемного» места в минипроге и правильность значений регистров..

Вот так у меня работает Монитор (скрин) при 2х ядрах и 4х кэшей у ЦП.
Примечание:
1) Для Board я добавил справочное сообщение: cpu freguence ..(выделено красным) которое показывает реальную тактовую частоту вашего ЦП, вычисленное системой Колибри.
Вы можете сравнить это значение с прогой GHOST MONITOR
(Для запуска GHOST MONITOR кликнуть в трее на вертикальную шкалу в нижнем правом углу возле часов).
Будет несовпадение значений при превышении тактовой частоты ЦП более 3300МГц .

2) Поток №1 IDLE ядра Колибри игнорируется «Монитором» — иначе появлялось бы сообщение каждые 5 сек. при простое системы


Если что не так с моим «Монитором» , напишите здесь какой у вас процессор и желательно скрин сообщений Board — будем думать.


Удачи

Jurgen wrote: ↑Sat Feb 17, 2024 11:33 amЕсли разработчик ядра, драйвера или приложения желает обезопасить механизм обработки данных при обращении к памяти для записи/чтения (например, к памяти полученной от пользователя), то он может сделать следующие действия:
1.) Перед обращением к памяти, установить следующие данные для обработчика "контролируемых исключений" ядра:
- В регистр edi занести сигнатуру - текст 'EXPT'

What do you mean by 'обезопасить'? In protected mode we have virtual memory for that. If a thread accesses invalid memory, just return something like -EFAULT and/or kill it. If you want to handle exceptions, you can set exception handlers via sf68.24 or use the debug API via sf69. I don't know what you are trying to do, but it's definitely not about memory safety.

Changing the kernel logic because of the magic value in edi doesn't look good either. If some code is unlucky to have 'EXPT' in edi, it will fail because there is nothing meaningful in esi. In short, your change isn't compatible with existing code.

dunkaist wrote: ↑Thu Feb 27, 2025 5:12 am

Jurgen wrote: ↑Sat Feb 17, 2024 11:33 amЕсли разработчик ядра, драйвера или приложения желает обезопасить механизм обработки данных при обращении к памяти для записи/чтения (например, к памяти полученной от пользователя), то он может сделать следующие действия:
1.) Перед обращением к памяти, установить следующие данные для обработчика "контролируемых исключений" ядра:
- В регистр edi занести сигнатуру - текст 'EXPT'

What do you mean by 'обезопасить'? In protected mode we have virtual memory for that. If a thread accesses invalid memory, just return something like -EFAULT and/or kill it. If you want to handle exceptions, you can set exception handlers via sf68.24 or use the debug API via sf69. I don't know what you are trying to do, but it's definitely not about memory safety.

Changing the kernel logic because of the magic value in edi doesn't look good either. If some code is unlucky to have 'EXPT' in edi, it will fail because there is nothing meaningful in esi. In short, your change isn't compatible with existing code.

Это альтернативный вариант обработчика исключений (без использ функций) для применения в пользовательском режиме или в режиме ядра.
Если вы считаете что эта вещь вам не нужна, то вы можете удалить его. Мне все равно

It was me who approved your write access to the repository. It was me again who advocated for you in the telegram chat when you broke the network in this commit. If I wanted to remove your code, I would have already done so. I don't want this.

Your priority is the Windows emulation project, no problem at all. My priority is KolibriOS. Therefore I am obviously interested to understand how KolibriOS can benefit from another exception handling mechanism. If it's something useful not only for the emulator (even in perspective), then great. For example, thread priority is a common and useful feature in many OSes. Maybe this is the case for your exception handling mechanism too. Please, elaborate.

Do I understand correctly that the new mechanism breaks existing code which is unlucky to have edi='EXPT' just before exception? If yes, can this be implemented in a compatible manner?

You are an experienced engineer without a doubt. I would be happy if you not only explained what you have done for your emulator but also suggested the way other KolibriOS developers could use these features.

By the way, we have finally switched from svn to git. Due to spam bots, registration is currently done by hand. Let me know if you need an account. Alternatively, just show up in the chat.

dunkaist wrote: ↑Sun Mar 16, 2025 6:01 am It was me who approved your write access to the repository. It was me again who advocated for you in the telegram chat when you broke the network in this commit. If I wanted to remove your code, I would have already done so. I don't want this.

Your priority is the Windows emulation project, no problem at all. My priority is KolibriOS. Therefore I am obviously interested to understand how KolibriOS can benefit from another exception handling mechanism. If it's something useful not only for the emulator (even in perspective), then great. For example, thread priority is a common and useful feature in many OSes. Maybe this is the case for your exception handling mechanism too. Please, elaborate.

Вот в этом посте,http://board.kolibrios.org/viewtopic.php?p=80284#p80284 в постскриптуме, я предложил участникам проекта Колибри совместную разработку и развитие ядра Колибри.
Я там не увидел ни одного комментария в поддержку моего предложения.

Поэтому, во избежание нарушения «тонкой душевной организации» отдельных участников сообщества (из-за «поломки» чего либо в ядре при внесении правок), принято решение вести разработку ядра Колибри самостоятельно.

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

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

dunkaist wrote: ↑Sun Mar 16, 2025 6:01 am Do I understand correctly that the new mechanism breaks existing code which is unlucky to have edi='EXPT' just before exception? If yes, can this be implemented in a compatible manner?

Конечно, в теории, могут так сойтись обстоятельства, что возникнет такая «неприятность» в пользовательском режиме. Однако для режима ядра пока нет другой альтернативы обработки возникших исключений ( для корректного завершения обработки «некорректных» данных полученных от пользователя).
По поводу вашего вопроса о возможности найти «совместимый вариант», исключающий такую «неприятность» для пользовательского режима - Да, это возможно.
Потом у себя в ядре попробую варианты — пока для меня это неактуально.

В принципе, вполне реально вы сами можете реализовать свой вариант корректной обработки исключений для режима ядра. И ваш вариант может оказаться лучше чем мой.

dunkaist wrote: ↑Sun Mar 16, 2025 6:01 am By the way, we have finally switched from svn to git. Due to spam bots, registration is currently done by hand. Let me know if you need an account. Alternatively, just show up in the chat.

Спасибо за предложение, возможно в будущем воспользуюсь вашим приглашением в git.

По поводу Телеграмм: В моем регионе провайдер заблокировал возможность регистрации в Телеграмм.
А ввиду того, что Дурова «продавили» на сотрудничество с французкими спецслужбам, то видимо никогда не разблокирует.