OSDev

Вот это на мой взгляд серьёзный архитектурный просчёт. Такой подход, вместо создания системы, в которой нет места ошибкам, приводит к созданию системы с постоянными разборками "кто виноват".

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я это продумывал. Мне и самому ненравится. НО в данном случае защитой было пожертованно в угоду прозводительности. А вся защита ложится на плечи разработчика. Запуск приложений будет разрешён только прошедших проверку и тестирование на соотвестие выполнния стандартов. И там будут зашиты тесты на корректную работу при паролельном исполнении. Корректная работа в паролельном режиме это забота разработчика ПО, а не ОС. хотя некоторые защитные механизмы есть и они скорее всего бдут внедрены.

Кто-виноват будет видно легко. Этис собственно система и будет заниматся и вести логи.

ПС. Под микроядром я понимаю изолированные процессы. А не процессы в разном адрестном пространстве. Что не обще принято.

Эххх, сними розовые очки. Даже в гигантских корпорациях работают самые обычные люди, которые тоже склонны допускать ошибки. Майкрософтовские драйверы для различного железа ИЗОБИЛУЮТ ошибками. Часто даже сам производитель чипсета не может написать корректный драйвер и (о, Боже!) игнорирует сообщения о найденных ошибках! Я уж не говорю про тысячи более мелких компаний. Многие из них даже не знают о стресс-тестировании драйверов, предусмотренных майкрософтом.


Не улавливаю разницы. Как изолировать процесс, не изолируя адресные пространства?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

это моё НОУ-ХАУ. Задачи находятся в одном процессе(имеют одно общее адрестное пространство), но изолируются странцами. Запрещена запись и выполнеие кода. Запись и выполнение кода разрешены только в своей задаче. При переходе от задачи к задачи одни страницы маскируются другие размаскируются. Передача данных эллементарна, так как страницы открыты на чтение. Переход и передача параметров осуществляется через ядро.

Что значит "изолируются страницами"? Я так понимаю, это делается перегрузкой содержимого регистра CR3? Если так, то это никакое не ноу-хау, а обычное разделение адресных пространств. То, что ты называешь страницами, открытыми на чтение, традиционно называется Shared memory (разделяемая память).

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

У меня вся память Shared memory.
CR3 не трогается изменяются только биты отдельных страниц(таблицы страницы).

Скорость переключения классная будет

Хммм.
В плане скорости...
скорость действительно может быть немного больше, если обработчики часто переключаются в рамках общего пространства друг на друга. Однако, в реальности, как я понимаю, переключение на обработчик происходит с какой-то задачи (возникло ведь прерывание). В данном случае перезагрузка CR3 обязательно произойдёт. То есть, скорость может совсем не возрасти. С другой стороны, для всех страниц с перегруженными атрибутами необходимо вызвать инструкцию invlpg, чтобы сбросить скешированные элементы TLB. Таким образом, для этих страниц элементы TLB всё равно будут подгружены заново, а с другой стороны, возрастут накладные расходы на алгоритм сброса кэшированных элементов. Также есть основания полагать, что перезагрузка CR3 на самом деле не сильно бьёт по производительности. Так, на доступ к каждым 4к памяти добавляется только 1 (а на каждые 4М памяти 2) чтение 4 байт из таблиц. В абсолютном исчислении это получится около 0.1% производительности.
В плане надёжности...
для работы с таким пространством требуется поддержание разделения доступа к страницам, что может внести свои ошибки. Кроме того, тот факт, что вся память по определению разделяемая, добавляет требование к тщательной проверке блокировок доступа. Таким образом, есть основания полагать, что надёжность в такой схеме страдает.
Резюме. Моё сугубо личное мнение: такая схема не даст выигрыша в производительности, а скорей всего даже немного проиграет, а также пострадает надёжность.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Так я в плане скорости иронически говорил. Ведь при каждом переключении придётся пробегаться по таблицам переадресации (а они могут быть очень большими), а затем ещё инвалидацию TLB делать (иначе изменения в таблицах не вступят в силу). В результате при каждом переключении будут сыпаться и кэши (из-за чтения-записи большого объёма данных), и TLB.