OSDev

У каждого процесса и так "свой" корневой каталог.
Но адресное пространство(АП) процесса состоит из двух:
1. Прикладное, пользовательское
2. Системное, ядерное.

Так вот в ядре есть динамические структуры стек страниц для загрузки и выгрузки DLL (динамические линкуемые библиотеки к примеру с драйверами)
Есть ядерная куча. В которой хранятся системные структуры:
1) список задач
2) дескрипторы файлов,
3) хэнделы сокетов
4) и другие структуры.
Эти структура динамическая т.е безразмерные. Я не ограничиваю их как в других ОС. Для краткости можете считать ограничения в 2^32 - т.е память кончиться раньше.
Так вот с изменением этих структур будут менять приделы размеры кучи и стека страниц. Следовательно при работе ядра корневой каталог будет меняться так как под новые приделы будут выделяться не только страницы, но и каталоги страниц.
В микроядре это всё вынесено в отдельный процесс или процессы и АП ядра фиксировано.

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

PS. Хочется узнать мнение и комментарии SII. Можно ли считать данное выше утверждения как критерий отделения моналита, от микроядра в изначальном смысле.

Речь идет о том, чтобы не изменять содержимое каталогов при переключении задач.

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

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

Вы явно невнимательно читали документацию. Вот выдержка от Интела про инструкцию IRET:

И что же мы видим ? А видим мы в том числе "Intra-privilege level return". Надеюсь нет нужды пояснять, что это такое ?

Ну и такая же ситуация с инструкциями CALL и JMP:

Подчеркну здесь фразу "within the current code segment". То есть как минимум про архитектуру IA32 в случаях вызовов процедур и работы с прерываниями мы можем говорить без трепета и придыхания, не заморачиваясь на сегменты, дескрипторы и прочий бред.

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

Пока что ситуация в мире ОС по сути остаётся в стане "метода тыка". Линухи с Виндами надувают щёки и не собираются думать об альтернативах. Ну а поскольку эти существа ещё и самые толстые работодатели для осеписателей, имеем кучу трактатов о том, как круто устроен Линух и какая на самом деле глубоко продуманная эта Винда. Поэтому если и не велосипед, то что-то близкое изобретать можно и нужно, поскольку в велосипедах от Линуха с Виндой наличествует масса неэффективных механизмов, связанных между собой ещё менее эффективным способом.

Мой "рекомменд" - используйте единое плоское адресное пространство. Но это, конечно же, применимо только для основанных на виртуальной машине осях (из-за безопасности, в основном).

Нужды нет, это возврат в код, который имеет то же уровень привилегий, что и обработчик прерывания. но при чем здесь сегменты? читайте дальше...

т.е. CS всегда извлекается из стека... надеюсь нет нужды пояснять что это такое?

Ну давайте померяемся умением читать документацию. Теперь предлагаю вам почитать том 3 выше упомянутого руководства и конкретно главу 2.4 MEMORY-MANAGEMENT REGISTERS. Затем переходите сразу к части 3-й 3-го тома под названием PROTECTED-MODE MEMORY MANAGEMENT.

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

Ну и могу вас уверить, что не только не найдёте, но ещё и практическое доказательство у меня имеется - скачайте мою ОС и запустите - в ней все возможные дескрипторы (кроме прерываний) тупо затираются. И ничего, работает. Так что зря вы ввязались в спор не понимая его сути.

Верно, CS всегда используется. Если есть сомнения, то лучше смотреть на алгоритм работы инструкции, описаной в Instruction referense.

Я делаю 2 вариант без обхода всех каталогов. Сначала создаю "главный" системный процесс, содержащий образцовый для всех остальных процессов каталог. Чтобы поддерживать консистентность, используются правила.
* При добавлении новой таблицы в директорию дочернего процесса, делается идентичная запись и в главной директории.
* Когда в другом дочернем процессе происходит исключение "пустая страница", т.к. в его каталоге новой записи ещё нет, то обработчик исключения проверяет наличие каталога в главном процессе для требуемого адреса, и если адрес ненулевой, то копирует этот адрес (только адрес), и возвращается к продолжению работы процесса.

...наличие таблицы

Хороший способ, если только добавлять транс-страницы. Делаешь ли удаление и если да, то как?

Вариант 2 – по-моему очевидный выбор для ОС общего назначения. Вопрос в том, как это реализовано.