OSDev

Теорию по осям почитайте, причём внимательно, разбираясь со всем, что там написано, а не абы как. Что именно -- особо не скажу, поскольку те книги, по которым учился, просто не найдёте (это издания ещё 1970-х, хотя, по большому счёту, принципиальные моменты не меняются уже с конца 1960-х). Из современных народ вроде хвалит Танненбаума. Естественно, можно (а в общем-то, и нужно) почитать по Винде и Линуху; по последнему мне в целом понравилась книжка Роберта Лава (название толком не помню) -- достаточно подробно описывает реализацию различных внутренних механизмов (другое дело, что далеко не всё в Линухе может служить образцом для подражания -- это скорей образец того, как не следует делать, но это уже другой вопрос).

Я сначала не стал говорить, но 2- и 4-мегабайтные страницы не альтернатива 4-килобайтным, а лишь дополнение для весьма специфического использования. За основу нужно брать 4-килобайтные страницы.

Да, хоть 108, только учти, что любая из них в этом случае может повредить другую, и им может быть тесно вместе, если они большие :)

Нет там длины каталога. Длина всегда фиксирована и зависит от режима страничной адресации.

Ядро системы и в старом адресном пространстве, и в новом должно находиться по одним и тем же адресам.

Оставь на время индексы. Лучше говорить о виртуальных адресных пространствах и их областях. Грубо говоря все вирт. адр. пространство делится на две части (не обязательно равные). Первая часть для прикладного кода, вторая - для кода ядра. Так вот область ядра (за исключением локальных данных ядра для конкретного пространства/процесса) отображается во все пространства по одним и тем же виртуальным адресам. По сути адресные пространства переключаются не целиком, а только область приложения и область локальных данных ядра. В каталоге соответственно часть входов будет соответствовать локальным областям, а часть глобальным. Могут быть и смешанные, но лучше так не делать и к примеру для обычной 32-битной адресации выравнивать границы областей на 4-мегабайтную отметку.

phantom-84, соглашусь с Вами. Я тоже подумал про то, что 4 МБ будет очень много (просто попусту буду память не использовать). 4 КБ в самый раз, однако больше заполнять (ведь тогда нужно делать табличку двухуровневую).

Пускай там длины нет (я про регистр CR3), но ведь я же не обязан заполнять в таблице каталога таблиц все 1024 элемента. И ведь не обязан в таблице страниц заполнять все 1024 элемента. Ведь если программа обратится к индексу, который не существует, то вызовется исключение (не знаю какое, но вроде бы общей защиты). Так ведь?

Хотя как вариант, заполнить все 1024 элемента в таблице первого уровня и в каждой такой таблице по 1024 элемента, с той разницей, что все не нужные пока для меня элементы будут ссылаться на одну и туже физическую область памяти ОЗУ в 4 КБ.

Кстати, на счёт книг, скачал себе:

1. Современные операционные системы (3-е издание);
2. Операционные системы. Разработка и реализация (3-е издание).

Надеюсь не зря скачал.

Как вариант, у меня крутится в голове следующее (на примере выдуманных диапазонов адресов)...

Адреса в диапазоне 0xFFC00000 - 0xFFFFFFFF у меня будут отведены под код ядра ОС. В этом диапазоне лежит 4194304 байта (4096 КБ, 4 МБ). То есть в CR3 попадёт такой адрес таблицы описания страничек, где в таблице первого уровня под индексом 0 будет указан адрес таблицы, где будут описаны 1024 элемента, как раз указывающие на диапазон 0xFFC00000 - 0xFFFFFFFF.

Когда код ядра ОС сделает своё чёрное дело, он передаёт управление программе пользователя, но до этого кое что сделав. Сначала он определяет в какую область физических адресов (страничного кадра) нужно будет засунуть код программы. На основании этих данных он строит таблицу страниц для регистра CR3. Вот он по определённым адресам скопировал код и данные программы пользователя. В таблице каталога таблиц под индексом 1023 будет идти указатель на таблицу страниц, где будет описан диапазон 0xFFC00000 - 0xFFFFFFFF (то есть код ядра ОС). И теперь ядро ОС записывает в CR3 адрес таблицы каталога страниц для текущей программы и передаёт управление по адресу 0x00000000 (Каталог 0, таблица 0, смещение 0), и программа уже выполняется.

Ну что-то типа такого. Хотя это только первая задумка, которую стоит перенести на листок бумаги и просмотреть все нюансы: что, куда, откуда и зачем. Я вот не знаю, правильной ли практикой является для каждой задачи изменять CR3 (то есть подстраивать каталог для каждой задачи). Разумеется для задачи может понадобиться всего 2 странички, поэтому чтобы ядро ОС анализировало служебную информацию в исполняемом файле программы и на основании этого составляло для программы верную таблицу каталога таблиц. В общем как-то так или я вообще не в ту сторону плясать начал?

_________________
Изучаю процессор...

Да, от того как материал изложен, определяется многое. Вот например хорошее определение:



Но тогда я загнан в тупик. Получается что для любой программы будет доступно 4 ГБ виртуальной памяти, которая будет описывать какой-то определённый участок. Да я могу все эти 4 ГБ описать одну и ту же физическую память в 4 МБ, просто подгружая туда данные с диска. Но волнует меня другое. Если для каждой программы будет своя таблица каталога таблиц (на который указывает регистр CR3), то получается что я же потеряю метку, где у меня хранится код ядра операционной системы (ОС).

Что я имею в виду, так вот...

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

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

_________________
Изучаю процессор...

А возможно ли сделать для 32-битной адресации трёхуровневую таблицу, чтобы каждая страничка занимала 2 КБ?

Или скажем двухуровневую, но чтобы каждая страничка была по 2 МБ?

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

_________________
Изучаю процессор...

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

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

Я тебе больше скажу. В длинном режиме "нужно делать табличку" четырехуровневую: PML4, PageDirTabs, PageDirs, PageTabs.

Так. Только длина от этого не перестает быть равной 1024-м. Исключение #PF (пэйдж фолт).

Предыдущий вариант значительно лучше.

Дай ссылку на 3-е издание (у меня 2-е). Какой формат?

Последние 4 мега. Последний вход каталога. Разве что только для кода ядра. Для таблиц ядра и для большого количества подгружаемых драйверов не хватит. Я делаю сборки с 1- и 2-гигабайтной областью ядра. Кстати в последнем входе у меня циклическая ссылка на каталог, поэтому последние 4 мега занимает таблица страниц.

Чтобы управлять пэйджингом, таблицы страниц также нужно отображать в вирт. адр. пространство.

Каталоги будут разные, но уже начиная со второго уровня глобальные фрагменты можно не дублировать.

Он не является физическим.

phantom-84, вот ссылка на книгу: http://depositfiles.com/ru/files/ticbngsue (формат DjVu).

В общем получается так, что желательно чтобы код ядра операционной системы был в конце каталога таблицы страниц. Чтобы для каждой задачи сохранялись важные системные данные (для регистров: LDTR, IDTR и CR3), чтобы можно было обрабатывать исключения и прерывания. А самой же программе пользователя просто запретить доступ к страничкам кода ядра операционной системы (установить для странички режим супервизора).

На сколько я понял, то для 32-битной адресации (режим P-Mode) можно использовать странички только лишь размером в 4 КБ, либо же в 4МБ (одно из двух). Как в этом случает разбивается 32-битный адрес мне понятно:

- страничка 4 КБ = 10 бит (каталог) + 10 бит (страничка) + 12 бит (смещение);
- страничка 4 МБ = 10 бит (страничка) + 22 бита (смещение).

Видимо я читал не внимательно, раз подумал что в регистре IDTR хранится физический адрес. Ведь если подумать, это было бы глупо, тогда страничная адресация была бы не совсем уместна (точнее не полностью эффективна).

А при 64-битной адресации (режим L-Mode) странички какого размера могут быть и соответственно для какого размера сколько уровней в таблице нужно? Сколько элементов в какой таблице может быть.

Есть у меня ещё идея (уж не уверен что стоящая), когда можно в последнем элементе каталога страниц хранить обёртку над системой. То есть когда вызывается прерывание или происходит исключение (хотя можно рассматривать оба этих понятия как одно и тоже), то передаётся управление в соответствующую номеру прерывания процедуру, которая находится в той физической памяти, куда указывает последний элемент в каталоге страниц. В свою очередь там будет храниться 256 обёрток, цель которых - это определить номер прерывания, сохранить информацию о задаче и загрузить в регистр CR3 другую таблицу, которая будет являться таблицей кода ядра операционной системы (конечно какие-то действия можно будет вынести в одну процедуру, чтобы каждое прерывание не делало одно и тоже). И после этого прыгать в код реальной обработки прерывания (который уже будет построен так, как программист считает нужным). А при отработке прерывания, назад возвращать значение регистра CR3 (если была не авария, в общем если разрешено программе дальше работать) и прыгать на инструкцию, вызвавшею исключение (или на следующую инструкцию, которая будет выполняться после инструкции int n). Ну а если программу продолжать не нужно, то подчистить за ней.

Такой вариант глупый? ))

_________________
Изучаю процессор...

2 мб (3 уровня) и 4 кб (4 уровня). В любой таблице 512 элементов.

Если я правильно тебя понял, то такой вариант имеет право на существование, но эффективность пострадает, хотя область приложения расширится.