OSDev

У меня 32-разрядное ядро, поэтому для начала расскажу, как это делается в IA-32. Действительно используется один или несколько смежных страничных фреймов (в моей терминологии стоп-фрейм - свободный фрейм, который не может быть использован для чего-либо еще). При переполнении стека ядра, т.е. при обращении к стоп-фрейму происходит страничное исключение, обработка которого приводит к повторному обращению к этому же стеку и как следствие к #DF. Обработчик #DF вешается на шлюз "искусственной" задачи, у которой имеется свой стек, поэтому дальнейших исключений не происходит. Из-за таких сложностей в обработке переполнения стека ядра в AMD-64 ввели поддержку независимых стеков для исключений/прерываний. Переполнение стека ядра обычно является критической ошибкой, приводящей к управляемой остановке системы. Переполнение прикладного стека обрабатывается значительно проще и обычно приводит к его автоматическому расширению, пока это возможно (у меня, например, дефолтный обработчик работает именно так, если для стека был зарезервирован доп. участок, т.е. когда MAXSTACKSIZE>MINSTACKSIZE, плюс часто возможно "ручное" расширение резерва "вниз" вплоть до стоп-фрейма, т.к. прикладной стек обычно имеет такой вид: stop free free free res res alloc alloc - обратите внимание на то, что роль начального стоп-фрейма играет обычный свободный фрейм, принадлежащий стеку). Чтобы переполнение стека ядра не приводило к хаотичным остановкам системы, в ядре есть спец. средства контроля глубины стека ядра, а также несколько функций, предоставляемых драйверам.

Кстати, размещение ядра в начале ВАП - не есть хорошо.

На самом деле, его без разницы, где размещать, если всё это дело хорошенько обдумать. Размещение Винды в старшей половине объясняется лишь тем, что так было в VAX/VMS. А вот в означенной системе такое размещение диктовалось архитектурой железа: системный код должен был выполняться именно в старшей половине адресов (подробно уж не помню, что там к чему -- в отличие от PDP-11, с VAX дела почти не имел; может, Йода помнит).

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

Всем спасибо за разъяснения. Вопрос решён стоп-фреймом. Решил сделать 0x100000-0x100FFF стоп-фреймом с presented=0, хотя и с write=0 тоже срабатывает (исключение из-за невозможности записать туда что-то своё).
Вообще, проблема надуманная, ибо у каждого драйвера или приложения стэки будут свои, а ядро на 3 метра вглубь вряд ли уйдёт, но на всякий случай решил таки перестраховаться.

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

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

У кого-то надуманная, а у кого-то нет...

К сожалению, не знаю. С Ваксами имел дело исключительно на прикладном уровне, не на системном. Это надо узнавать у Дэвида Катлера .


Ничуть не бывало. Это по большей части религиозно-политический вопрос, сродни войнам тупоконечников с остроконечниками. В нормально спроектированной системе (релокируемый код, макроопределения, настраиваемые таблицы адресов функций...) баланс нормально соблюдается и в top-half и в bottom-half ядре. Лично я располагаю ядро внизу по той причине, что самостоятельно инициализирую всё через BIOS с использованием первого мегабайта, а в дальнейшем оставляю все адреса на своих местах.

DJ PhoeniX,
Речь идёт о виртуальном адресном пространстве? Если да, то не пойму, в чём проблема, ведь в long mode BIOS не может быть использован, а следовательно на его адреса можно спокойно мапировать свободные страницы памяти. То же самое касается и видео-БИОСа. А видео-буфер может быть мапирован на любой адрес. Таким образом, стек можно без опаски опускать вплоть до нуля.

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

Кстати говоря, подумал об этом. А что будет, если стек опустится до нуля?

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

Честно говоря, не знаю, что будет в long-mode при зацикливании указателя стека. Надо читать доки.
Если речь идёт о твоём проекте, то непонятно, что заставляет размещать стек по этим адресам. Есть два стека - стек пространства ядра, он, как правило, очень маленький и в большинстве систем помещается в одну-две страницы, и стек пространства пользователя, он может быть любым. Обычно его размещают в верхушке доступного виртуального адресного пространства.

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

Повторяемся... Зачем постоянно релоцировать приложение, когда было бы вполне разумно в большинстве случаев вообще убрать релоки из основного модуля приложения? Я тоже "инициализирую всё через BIOS с использованием первого мегабайта", но это мне не мешает размещать рабочую часть ядра в верхней части ВАП. Инициализационные секции ядра имеют привязку к младшим адресам, "рабочие" секции - к старшим. Кстати инициализационный код может также работать в начале второго мега, причем как в PM, так и в RM.

А я помню, что это единственное, что мне откровенно не понравилось в VAXовской архитектуре -- как-то притянуто за уши показалось, причём без всякой нужды...



А у меня ядро может быть вообще где угодно -- иначе на АРМах нормальной жизни не будет. Например, у одних по нулевым адресам лежит встроенная флэш-память, а её не хочется каждый раз переписывать, отлаживая систему, и поэтому грузишь её в ОЗУ куда-то повыше. Ну а у других там именно ОЗУ, ну и т.д.



Точно нельзя использовать вообще? Не только классический BIOS, но и UEFI? А то я в современных ПКшных реалиях плаваю...